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Kxecutive  Summary 

CONCEPT  AND  PLAN  FOR  MODERNIZING  THE  DEFENSE  LOGISTICS 

STANDARD  SYSTEMS  (DLSS) 


The  Modernization  of  Defense  Logistics  Standard  Systems  (MODELS)  project 
will  increase  the  capacity  and  flexibility  of  DoD’s  logistics  operations  by  redesigning 
and  upgrading  the  Defense  Logistics  Standard  Systems  (DLSS). 

To  take  advantage  of  advances  in  logistics  information  management  practices, 
as  well  as  telecommunications  and  data  processing  technology,  the  DLSS  must 
undergo  two  aspects  of  modernization  simultaneously:  ( 1)  functional,  that  is  enhanc 
ing  and  expanding  current  procedures  and  transactions  for  communicating  logistics 
information,  and  (2)  technical,  upgrading  the  capabilities  of  the  hardware  and 
software  of  the  various  information  processes. 

From  the  functional  view,  we  recommend  formulating  revised  variable-length 
DLSS  transactions  in  place  of  the  present  80-column  format. 

From  the  technical  view,  we  recommend  upgrading  the  DAAS  to  a  distributed 
network  configuration  consisting  of  interconnected  logistics  gateway  nodes  (LGNs). 
LGNs  pass,  route,  edit,  and  perform  special  processing  functions  for  transactions 
entering  and  leaving  the  logistics  sites  they  support.  They  offer  the  potential  of  a 
significant  increase  in  its  functional  capability  and  a  reduction  in  communication 
costs.  - - — 
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SECTION  I 


FUNCTIONAL  CONCEPT  FOR  LOGISTICS 
INFORMATION  FLOWS 

1.1  INTRODUCTION 

The  Defense  Logistics  Standard  Systems  (DLSS)  define  the  requirements  for 
effective  communication  and  interactions  between  organizations  within  the  defense 
logistics  community.  They  consist  of  discrete,  but  compatible  systems  of  procedures 
and  transaction  formats  which  enable  the  effective  interaction  between  and  among 
organizations. 

Administered  by  the  Defense  Logistics  Standard  Systems  Office  (DLSSO),  the 
DLSS  play  a  critical  role  in  many  logistics  functions,  including:  cataloging, 
inventory  management,  contracting,  contract  administration,  storage,  distribution 
and  redistribution  of  materiel,  transportation  and  movement,  maintenance, 
property  disposal,  international  supply  support,  integrated  support  of  weapons,  and 
billing  and  collections.  The  DLSS  also  include  hardware  and  software  systems 
responsible  for  editing  and  routing  a  large  percentage  of  all  logistics  communi¬ 
cations  between  the  Services,  other  Federal  agencies,  and  outside  entities  including 
commercial  contractors  and  foreign  customers. 

The  DLSS  have  evolved  over  the  past  20  years.  During  that  time,  and  on  an 
ongoing  basis,  new  logistics  information  requirements  have  been  identified.  The 
DLSS  must  respond  to  this  continuing  need.  However,  effective  logistics 
management  has  increasingly  been  impeded  due  to  the  obsolescence  of  some  existing 
procedures.  In  addition,  escalating  communication  demands  make  greater  capacity 
a  necessity. 

Along  with  growing  internal  requirements,  dramatic  changes  in  telecommuni 
cations  and  data  processing  technologies  have  spotlighted  the  need  to  upgrade 
systems  to  meet  current  standards.  To  capitalize  fully  on  new  capabilities  and  meet 
the  changing  needs  of  the  logistics  community,  DoD  must  replace,  rather  than 
modify,  existing  DLSS. 


There  is  ample  evidence  that  a  change  in  system  architecture  to  a  distributed 
rather  than  centralized,  configuration  is  required  (see  Section  3).  However,  before 
new  transaction  methods  and  procedures  can  be  designed,  the  manner  in  which 
logistics-related  information  flows  between  system  users  must  be  examined  in 
greater  depth. 

The  first  set  of  charts,  represented  in  Figures  1-1  through  1-6,  illustrate  the 
work  breakdown  structure  (WBS)  defined  in  the  second  Modernization  of  the 
DEfense  Logistics  Standard  Systems  (MODELS)  report.  1  They  illustrate  the  full 
scope  of  logistics  functions  that  should  eventually  have  standardized  procedures  and 
transactions.  They  include  performance  measurement  (evaluation  of  system 
performance  is  currently  not  possible  on  a  centrally  aggregated  basis);  secondary 
item  acquisition  (including  procurement  and  contract  administration);  supply 
(requisitioning  and  inventory  management);  transportation  (tracking  the  movement 
of  personnel,  supplies,  etc.);  and  reutilization  and  marketing  (the  handling  of  excess 
property). 

The  information  flow  diagrams  which  make  up  the  balance  of  Section  1  identify 
the  information  requirements  that  must  be  incorporated  into  the  design  of  a 
modernized  DLSS.  The  analysis  is  presented  in  terms  of  subject  areas.  Specific  data 
elements,  or  units  of  information  will  need  to  be  developed  in  coordination  with 
DLSS  Administrators  and  Service/Agency  participants  based  on  recommended 
DLSS-  transaction  syntax.  In  addition,  management  or  policy  issues  on  control  of 
the  new  procedures  and  final  transaction  definition  are  not  discussed. 

One  new  system  capability  is  not  presented  here  but  is  highly  recommended: 
acknowledgments  to  a  sender  to  confirm  that  a  transaction  was  received,  called 
transaction  receipt  acknowledgments,  should  be  standardized  and  automatic 
throughout  the  system.  Each  would  carry  minimal  information,  including  source 
and  destination  data  in  the  header  record  and  a  transaction-unique  identifier  key 
with  a  one-character  receipt  acknowledgment  code.  The  capability  will  provide 
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compatibility  with  commercial  systems  being  designed  using  the  Electronic  Data 
Interchange  American  Standards  Institute  X12  (EDI)  concepts. s 

1 .2  DESIGN  OF  THE  FUNCTIONAL  INFORMATION  FLOW  DIAGRAMS 

The  flow  diagrams  in  the  remainder  of  this  section  start  at  the  second-tier  of 
the  WBS.  The  outline  of  the  function  boxed  descriptors  denotes  the  following: 


•  Solid  line  boxes. 


,  indicate  the  function  was  addressed  below  the 


second-tier  level  in  the  MODELS  functional  requirements  and  will  be 
addressed  in  the  initial  transactions  development  projects. 

I - 1 

Dashed  line  boxes.  _ J  ,  indicate  the  function  is  not  part  of  the  current 

DLSS  and  that  policy  decisions  concerning  the  level  of  interface  or  inte 
gration  into  the  DLSS  set  of  logistics  standards  must  be  made  before 
transaction  development  will  commence.  However,  they  are  shown  in  the 
diagrams  only  because  they  are  significant  sources  or  receivers  of  logistics 
information  standardized  by  DLSS  policies  and  procedures  and,  therefore, 
may  be  impacted  by  DLSS  transaction  redesign. 


Double-solid  line  boxes. 


indicate  that  information  flows  to  a  data 


collector  (e.g..  Weapons  System  Manager),  rather  than  a  logical  function 
(e.g..  Discrepancy  Reporting). 

The  conceptual  flow  diagrams  in  this  section  will  become  the  basis  for: 

•  Identifying  organizational  sources  of  and  destinations  for  information 

•  Identifying  logical  grouping  of  data  elements  for  building  transaction  data 
segments  and  data  records 

•  Developing  information  flow  models  to  analyze  the  impact  of  variable- 
length  transactions  on  logistics  communications  facilities 

•  Policy  and  procedure  decisions  on  organizational  responsibility  for  infor 
mation  processing. 

The  information  flow  diagrams  are  presented  in  the  remainder  of  this  section  of 
our  report.  Acronyms  not  defined  in  the  figures  are  defined  in  Appendix  A.  Each 
diagram  consists  of  inflow-function-outflow  charts  augmented  by  brief  narratives 
covering  each  of  the  second-tier  logistics  functions  shown  in  Figure  1-1.  The 
numbering  used  in  the  diagrams  relate  to  those  in  the  Figure  1-1  WBS.  Supporting 
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each  of  the  second-tier  logistics  functions  are  diagrams  showing  subsidiary 
functions. 

1.2.1  Performance  Measurement 

Figure  1-7  depicts  second-tier  logistics  functions  for  performance  measure 
ment.  This  function  collects  data  to  compare  current  performance  against  estab¬ 
lished  mission  objectives  and  goals.  Performance  measures  and  statistics  provide 
data  to  establish  future  goals  and  objectives  and  to  determine  requirements. 
Figure  1-2  shows  the  six  subfunctions  of  performance  measurement. 

•  Retail  inventory  management  collects  information  from  both  wholesale  and 
retail  organizations  to  provide  detailed  and  summarized  performance 
measures  of  the  effectiveness  of  the  retail  materiel  management  activity. 

•  Wholesale  inventory  management  collects  information  on  the  performance 
of  wholesale  supply  inventory  management  activities. 

•  Pipeline  performance  collects  information  to  measure  both  the  movement  of 
requirements  for  material  and  materiel. 

•  Contracting  collects  information  concerning  the  efficiency  of  the  contract 
ing  process  from  identification  of  procurement  through  completion  or 
termination  of  the  contract. 

•  Intefund  billing  provides  for  payment,  between  Government  organizations, 
for  supplies  and  services  provided  from  the  wholesale  to  the  retail  levels  for 
consumption.  This  measurement  system  collects  information  concerning 
the  timeliness  and  accuracy  of  this  funds  transfer  process. 

•  Weapons  system  management  collects  information  concerning  the  effective 
ness  of  logistics  functions  in  meeting  the  requirements  of  weapons  system 
managers  and  special  programs. 

The  inflows  and  outflows  for  each  of  these  are  shown  in  Figures  1-8  to  1-12. 

1 .2.2  Secondary  Item  Acquisition 

There  are  two  major  subfunctions  (shown  in  Figure  1-3)  under  secondary  item 
acquisition:  procurement  and  contract  administration.  Procurement,  with  inflows 
and  outflows  shown  in  Figure  1  13.  includes  all  the  transactions  related  to  the 
process  of  procuring  equipment  or  supplies  other  than  primary  weapons  systems  or 
end  items.  Contract  administration,  shown  in  Figure  1-14,  includes  technical 
administrative  transactions  to  the  contracting  administration  officer. 
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FIG  1-7  PERFORMANCE  MEASUREMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

PERFORMANCE  MEASUREMENT 
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FIG.  1-8  PERFORMANCE  MEASUREMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

RETAIL  INVENTORY  MANAGEMENT 


a 


m 


•  '  •***< yr#T<pr't  *<♦  »:t,  P*ticn»r*c  ,  'WPaSofPS  < •»  } 
p'age  t:  Df.xwi  *  DfOc«f*,m«?rt  'pQuesti 
:  2  'jnt'ai?  •»**<*'*  **"*%* '***M*ur*s 

•  -'or^o^'  *  ae«  «*»'  *s  "u^oer  .»  •‘»o*j't^a 


•:  .v*'  1  ■ 


~  SP  «pu!  '  /  II  '.-n  i ''Q  .'  ;  j 


•">»  ,r,  ->p<,  rf  o r-'Ts+r-j 


r  *»■•■«%  Ip  ’,  '*,^0**' 


.,*<~>p  or  •  ina  i  stv '^3  *  -jyr.r.j  •►'p  ,,11-tp  • 


c",s  ip^n  r>**f  •  '  •  ?-*.g-  -  * 


FIG.  1-9.  PERFORMANCE  MEASUREMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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FIG.  1-12.  PERFORMANCE  MEASUREMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 
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FIG.  1-13.  SECONDARY  ITEM  ACQUISITION  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

PROCUREMENT 
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1.2.3  Retail  Operations 


As  shown  in  Figure  1-4,  MODELS  is  fully  addressing  only  one  subfunction 
under  retail  operations,  retail  requisitioning.  This  requisitioning  function  includes 
not  only  requisition  processing  as  shown  in  Figure  1-15,  but  also  pipeline  status, 
receipt  acknowledgment,  report  of  discrepancy,  excessing,  and  shipment  as  shown  in 
Figures  1-16  to  1-20. 


1 .2.4  Wholesale  Inventory  Management 


The  next  second-tier  logistics  supply  function  shown  in  Figure  1-4  is  wholesale 
inventory  management.  It  consists  of  the  following: 


•  Requirements  computation  and  acquisition  inflows  and  outflows 
(Figure  1-21)  include  information  flows  related  to  the  determination  of 
wholesale  requirements  and  the  acquisition  of  stock  to  meet  those 
requirements. 


•  Cataloging  (Figure  1-22)  supports  all  inventory  management  requirements 
for  item  identification,  cataloging  data  reference,  and  retrieval. 


•  Inventory  control  inflows  and  outflows  (Figure  1-23)  cover  maintenance  of 
stock  levels  and  replenishments,  and  management  of  accountable  inventory 
records. 


J 


•  Distribution  and  redistribution  information  flows  (Figure  1-24)  include 
those  related  to  positioning  and  movement  of  wholesale  stocks  between  and 
to  wholesale  sites. 


Repair  and/or  rebuild  includes  the  information  inflows  and  outflows 
(Figure  1-25)  to  support  the  decision  to  repair  and/or  rebuild  reparable 
items. 


•  Requisition  processing  (Figure  1-26)  includes  all  inventory  management 
supply  decisions  necessary  for  requisitioning. 


•  Retail  excess  processing  inflows  and  outflows  (Figure  1-27)  are  those  related 
to  review,  authorization,  and  disposition  of  excess  materiel  reported  from 
below  the  wholesale  level. 


•  Excessing  (Figure  1-28)  shows  the  inflows  and  outflows  related  to  review, 
authorization,  inventory  adjustments,  and  disposition  of  excess  materiel  at 
the  wholesale  level. 


•  Discrepancies  (Figure  1-29)  includes  information  flows  for  the  documen 
tation  and  resolution  of  materiel  and  shipments. 
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FIG.  1-15.  RETAIL  OPERATIONS  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  REQUISITIONS 
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FIG.  1-17.  RETAIL  OPERATIONS  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 
RECEIPT  ACKNOWLEDGMENT 
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FIG.  1-18.  RETAIL  OPERATIONS  TRANSACTION  INFLOWS  AND  OUTFLOWS 

REPORT  OF  DISCREPANCY 
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FIG.  1-19.  RETAIL  OPERATIONS  TRANSACTION  INFLOWS  AND  OUTFLOWS 

EXCESSING 
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FIG.  1-20.  RETAIL  OPERATIONS  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  SHIPMENTS 
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FIG.  1-21 .  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
REQUIREMENTS  COMPUTATION  AND  ACQUISITION 
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FIG.  1-22.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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FIG.  1-23.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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FIG.  1-24.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

DISTRIBUTION  AND  REDISTRIBUTION 
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FIG.  1-25.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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FIG.  1-26.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 

REQUISITION  PROCESSING 
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FIG.  1-27  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

RETAIL  EXCESS  PROCESSING 
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FIG.  1-28.  WHOLESALE  INVENTORY  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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1.2.5  Technical  Data  Management 


The  next  second-tier  logistics  supply  function  shown  in  Figure  1-4  is  technical 
data  management.  It  ccmsists  of  the  following: 

•  Cataloging  includes  the  inflows  and  outflows  (Figure  1-30)  of  information 
for  the  identification,  notation,  indexing,  configuration  management,  and 
preparation  for  filing  of  technical  specifications,  drawings,  pictures,  etc., 
acquired  as  technical  data. 

•  Storage  inflows  and  outflows  (Figure  1-31)  include  the  storage  of  technical 
specifications,  drawings,  pictures,  etc.,  for  manual  and  electronic  retrieval 
in  response  to  inquiries. 

•  Retrieval/exchange  (Figure  1-32)  shows  the  process  of  finding,  collecting, 
and  collating  technical  information  from  contractors,  etc.,  for  dissemination 
and  distribution  to  authorized  users. 

1.2.6  Wholesale  Storage 

The  last  second-tier  logistics  supply  function  shown  in  Figure  1-4  is  wholesale 
storage.  It  consists  of  the  following  third-tier  logistics  supply  functions: 

•  Receipt  inflows  and  outflows  (Figure  1-33)  include  receipt  processing  at  the 
wholesale  level,  including  inspection,  acceptance  related  actions,  and 
update  of  inventory  records. 
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•  Warehouse  (depot  operations)  information  flows  (Figure  1-34)  concern  the 
physical  operation  of  warehousing,  including  stowage  and  maintenance  of 
materiel  in  stockage. 

•  Physical  inventory  information  inflows  and  outflows  (Figure  1-35)  account 
for  and  control  stock  on  hand,  including  physical  counting,  reconciliation  of 
discrepancies,  location  surveys,  etc. 

•  Issue  information  flows  (Figure  1-36)  are  related  to  processing  issue 
requests,  stock  selection,  confirmation/denial,  and  tender  of  materiel  to  the 
transportation  functions. 

•  Shipment  inflows  and  outflows  (Figure  1-37)  include  information  related  to 
the  physical  preparation  of  materiel  for  shipment,  depending  on  the  mode  of 
shipment. 
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FIG.  1-30.  TECHNICAL  DATA  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS 
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FIG.  1-31.  TECHNICAL  DATA  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  STORAGE 
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FIG.  1-32.  TECHNICAL  DATA  MANAGEMENT  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 
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FIG  1-33  WHOLESALE  STORAGE  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  RECEIPT 
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FIG.  1-35.  WHOLESALE  STORAGE  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 
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FIG.  1-36.  WHOLESALE  STORAGE  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  ISSUE 
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FIG  1-37  WHOLESALE  STORAGE  TRANSACTION  INFLOWS  AND  OUTFLOWS  - 

SHIPMENT 


1.2.7  Transportation  Authorization 


As  shown  in  Figure  1-5,  there  are  three  second-tier  logistics  transportation 
functions.  The  transportation  authorization  function  inflows  and  outflows  are 
shown  in  Figure  1-38.  They  include  the  process  of  specifying  movement  require¬ 
ments  to  the  transportation  provider. 

1.2.8  Traffic  Management 

The  second-tier  logistics  transportation  function  is  traffic  management.  This 
function,  whose  inflows  and  outflows  are  shown  in  Figure  1-39,  includes  the 
planning,  routing,  scheduling,  and  control  of  materiel  movements.  There  are 
diagrams  for  the  following  two  traffic  management  subfunctions: 

•  Movement  monitoring  information  flows  (Figure  1-40)  include  tracking 
materiel  from  point  of  origin,  through  intermediate  terminals  and  or  modes 
(different  carriers)  to  destination. 

•  Rerouting/diversion  information  flows  (Figure  1-41)  include  changing 
routing  or  changing  the  mode  or  carrier. 

1.2.9  Movement 

The  last  second-tier  transportation  function  is  related  to  the  operation  of 
transportation  terminals  and  carriers.  The  inflows  and  outflows  for  this  movement 
function  are  shown  in  Figure  1-42. 

1.2.10  Reutilization  and  Marketing 

As  shown  in  Figure  1-6,  the  reutilization  and  marketing  function  has  four 
second-tier  logistics  functions.  The  inflows  and  outflows  for  item  visibility  are 
shown  in  Figure  1-43.  This  function  provides  visibility  of  secondary  item  assets 
declared  excess,  including  such  information  as  quality,  location,  and  condition.  The 
remaining  second-tier  function  —  reutilization,  sale,  and  scrap  and  waste  —  ensure 
that  materiel  excesses  are  screened  and  utilized  to  the  fullest  extent  practical  by 
other  DoD  activities  or  Federal  agencies.  The  inflows  and  outflows  for  these 
functions  are  shown  in  Figure  1-44. 
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FIG.  1-38.  TRANSPORTATION  TRANSACTION  INFLOWS  AND  OUTFLOWS  -  AUTHORIZATION 
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ANALYSIS  OF  ARCHITECTURES  TO  SUPPORT 
THE  MODELS  REQUIREMENTS 


2.1  BACKGROUND 


The  MODELS  Functional  Requirements1  describes  two  alternatives  to  the 
existing  logistics  system  architecture.  Those  alternatives  were  analyzed  in  terms  of 
the  DoD-wide  logistics  system  effectiveness  and  vulnerability.  The  existing  system 
architecture  against  which  the  alternatives  are  compared  consists  of  the  two  Defense 
Automatic  Addressing  System  (DAAS)  facilities  that  route  documents,  provide 
system  interfacing,  and  perform  value-adding  functions  to  provide  interoperability 
among  the  activities  of  the  logistics  system.  The  existing  system  and  the 
two  alternative  architectures  are  shown  in  Figure  2-1. 


The  existing  DAAS  provides  a  broad  range  of  services  that  are  essential  to  the 
logistics  community  (see  Appendix  B).  Those  services  were  reviewed  during  the 
development  of  the  alternative  architectures  to  ensure  that  all  the  essential  ones 
would  be  retained  in  a  manner  compatible  with  ongoing  and  future  requirements  of 
DoD.  Additional  services,  not  currently  performed  by  DAAS,  were  also  considered 
for  incorporation  into  the  architectural  alternatives.  These  enhanced  capabilities 
are  defined  on  the  basis  of  the  recommendations  of  the  Functional  Requirements. 


The  first  alternative  is  an  expansion  of  the  existing  configuration  to  include 
additional  nodes  functioning  in  the  same  manner  as  the  current  DAAS.  That 
alternative  offers  the  potential  for  reducing  system  vulnerability  and  provides 
limited  additional  operational  benefits.  However,  those  benefits  are  offset  by  a 
substantial  increase  in  system  acquisition,  operations,  and  maintenance  costs. 


The  second  alternative  significantly  modifies  the  services  of  the  two  existing 
DAAS  sites.  It  augments  the  Dayton.  Ohio  site  with  individual  processors  at  major 
logistics  installations.  The  Dayton,  Ohio  DAAS  site  would  provide  the  centralized 
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services  required  by  the  logistics  system.  These  distributed  logistics  installation 
processors  [which  were  called  gateway  processors  (GPs)  in  the  Functional 
Requirements],  are  now  called  logistics  gateway  nodes  (LGNs).  The  LGNs  will 
perform  passing,  routing,  editing,  and  special  processing  functions  similar  to  those 
performed  by  DAAS.  However,  each  LGN  will  perform  these  functions  only  for 
transactions  entering  and  leaving  the  logistics  site(s)  it  supports. 

A  preliminary  analysis  shows  that  the  implementation  of  LGNs  will  signifi¬ 
cantly  reduce  system  vulnerability,  increase  system  functional  capability,  and 
reduce  communications  costs.  Since  the  LGN  architecture  includes  the  installation 
of  an  interface  gateway  at  major  logistics  installations,  the  logistics  system  will  be 
distributed  over  many  sites.  As  a  result,  system  vulnerability  is  no  greater  than  that 
of  the  individual  site.  Functional  capability  is  improved  because  of  the  increased 
flexibility  of  the  LGN  architecture  to  accommodate  changes  at  individual  sites  and 
the  elimination  of  a  requirement  for  storage  of  redundant  centralized  data  bases. 
Communications  costs  are  reduced  by  eliminating  multiple  transmission  of 
messages  through  DAAS  centralized  nodes.  Thus,  the  LGN  alternative  offers  the 
potential  for  enhancing  existing  logistics  system  effectiveness. 

The  LGN  architecture  represents  a  significant  change  from  the  current 
’'DAAS-based”  architecture.  Thus,  while  the  LGN  architecture  appears  to  offer 
many  advantages  over  the  existing  system,  it  must  be  analyzed  in  greater  detail 
before  reaching  a  final  decision  regarding  its  implementation.  A  preliminary 
functional  description  and  cost  estimate  must  be  undertaken  for  the  LGN  architec¬ 
ture.  Subsequent  steps  during  a  prototype  test  and  evaluation  effort  should  include 
preparation  of  a  functional  description  in  adequate  detail  to  permit  development  of 
accurate  estimates  of  LGNs. 

The  remainder  of  this  section  describes  the  LGN  architecture,  locations  served, 
functions  performed,  and  data  bases  used.  It  describes  hardware  and  software 
required  to  support  these  functions  and  a  preliminary  estimate  of  their  cost.  It  also 
provides  recommendations  on  management  and  organizational  issues  associated 
with  implementing  the  LGN  architecture. 

2.2  LOGISTICS  GATEWAY  NODE  ARCHITECTURE 

The  following  section  provides  an  overview  of  the  LGN  architecture,  gives 
examples  of  typical  operations,  and  provides  additional  information  on  several  key 


points  of  the  concept.  A  technical  description  of  the  concept  is  provided  in 
subsequent  sections. 

2.2.1  Overview  of  Operation 


The  basic  framework  of  the  DLSS  LGN  architecture  is  illustrated  in  Figure  2  2. 
It  provides  for  a  network  of  identical  communications  processors,  designated  LGNs, 
linked  by  existing  and  evolving  communications  systems  [such  as  Defense  Data 
Network  (DDN)].  In  general,  each  LGN  performs  the  same  routing,  passing,  and 
error-checking  functions  now  performed  by  DAAS.  Each  also  performs  the 
formatting  and  translation  functions  required  to  interface  with  other  automatic  data 
processing  equipment  ( ADPE)  at  its  user  site.  Each  LGN  would  communicate  with 
other  LGNs  (or  the  Central  LGN  in  Dayton.  Ohio)  using  standard  DLSS  formats  and 
data.  Each  LGN  would  interface  with  a  specific  Service/Agency  (S/A)  set  of  users  in 
formats  and  data  unique  to  that  set  of  users.  For  example,  Army  National  Inventory 
Control  Point  ( NICP)  user  interfaces  may  be  standard  but  different  from  the  Defense 
Logistics  Agency  (DLA)  NICP  interfaces.  From  a  systems  viewpoint  it  is  desirable  to 
have  all  LGN/user  interfaces  standard.  However,  that  standardization  is  not 
currently  practical.  A  full  discussion  of  LGN  functions  is  presented  later  in  this 
section. 

The  Central  LGN  would  interface  with  its  Joint  Command,  OSD.  and  S-A 
"customers”  through  terminals  and/or  computer  links.  The  nature  of  each  of  these 
interfaces  requires  additional  definition.  A  more  complete  description  of  the  Central 
LGN  is  also  presented  later  in  this  section. 

2.2.2  Illustrative  Examples 

The  following  examples  illustrate  the  potential  operation  of  the  LGN  architec 
ture.  The  examples  may  be  tracked  in  Figure  2-2. 

2.2.2. 1  Example  1:  Routine  Requisition  and  Shipment 

In  this  example,  the  requisition  originates  in  an  S/A  activity  and  is  processed 
by  S/  A  systems  and  procedures.  It  contains  DLSS-specified  data  and  S  A-unique 
data  in  a  variable-length  record.  At  the  LGN  site  (the  point  at  which  the  S  A 
interfaces  with  the  wholesale  logistics  system),  the  data  are  reformatted  for  trans 
mission  using  a  DLSS  format.  The  LGN  routes  the  requisition  to  the  appropriate 
NICP  using  table  driven  software.  At  the  NICP,  a  second  LGN  passes  the 
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requisition  to  the  NICP  for  further  processing.  The  NICP  prepares  a  Materiel 
Release  Order  (MRO)  and  transmits  it  to  the  appropriate  depot.  The  MRO  would  be 
transmitted  back  through  the  NICP  LGN  to  the  LGN  supporting  the  depot. 

The  depot  notifies  the  appropriate  transportation  agency  to  ship  the  supplies, 
and  notifies  the  requester  that  supplies  are  being  shipped  using  standard  DLSS 
formats.  This  notice  of  shipment  would  be  directed  through  the  depot’s  LGN  to  the 
appropriate  LGN  of  the  S/A. 

On-line  requesting  will  be  available  for  designated  critical  items  for  the  facili 
ties  that  can  utilize  these  advanced  capabilities. 

2.2. 2. 2  Example  2:  The  Primary  Source  of  Supply  (SOS)  Is  Out  of  Stock 

In  this  example,  the  requisition  cannot  be  filled  at  the  primary  SOS  and  is 
electronically  directed  to  an  alternative  SOS.  (Note:  This  capability  will  require 
some  enhancements  to  S/A  supply  management  systems.)  The  requester  is  not 
notified  of  the  redirection  unless  a  longer  ordering/shipping  time  is  projected.  In 
that  case  the  requester  would  be  notified  in  a  standard  DLSS  format  routed  to  the 
appropriate  LGN  for  transfer  to  the  requester. 

2. 2.2. 3  Example  3:  The  Item  Is  Out  of  Stock  in  the  Wholesale  System 

If  the  wholesale  system  does  not  have  the  item,  in  the  short  term  the  NICP  will 
notify  the  requester  through  the  appropriate  standard  DLSS  transactions  sent  to  the 
requester's  LGN.  This  notification  will  contain  the  DLSS-prescribed  data  and  such 
other  information  as  may  be  appropriate  to  the  situation,  e.g.,  a  narrative  message 
indicating  an  estimate  of  when  the  stock  will  be  available. 

In  the  longer  term,  the  NICP  or  other  designated  agency  would  use  the  LGN  to 
initiate  a  search  of  the  worldwide  retail  inventory  and  reutilization  and  marketing 
(R&M)  assets  to  determine  availability  of  the  needed  supplies.  The  R&M  search 
could  be  performed  on-line. 

2.2.2 A  Example  4:  The  Requested  Supplies  Do  Not  Arrive  Within  the  Expected 
Order  and  Ship  Time 

In  the  event  that  the  requested  supplies  fail  to  arrive  within  the  required 
order/ship  time,  follow-up  action,  either  computer-  or  human-generated  must  be 


taken.  Standard  DLSS  follow-up  formats,  augmented  with  S/A  systems  and 
procedures  if  necessary,  will  follow  the  same  path  as  the  requisition.  When  the 
requisition’s  status  is  determined,  the  user  is  notified  through  the  appropriate  LGN 
to  the  requesting  S/  A  system.  If  the  supplies  have  been  shipped,  the  shipping  supply 
activity  notifies  the  initial  transportation  activity  for  continuation  of  the  follow-up 
and  the  requester  is  notified  (using  the  LGN)  that  the  supplies  have  been  shipped. 
Transportation  activities  continue  the  follow-up  action  and  notify  the  requester 
when  they  determine  the  status.  In  the  fully  developed  system  and  related  S/A 
systems,  this  entire  process  will  be  electronic. 

2.2.2. 5  Example  5:  The  Joint  Chiefs  of  Staff  (JCS)  Needs  Information  on  the  Status 
of  a  Critical  Item  fora  Priority  Decision 

In  this  example,  the  appropriate  Organization  of  the  Joint  Chiefs  of  Staff 
(OJCS)  element  would  frame  a  global  inquiry  and  submit  it  to  the  Central  LGN 
using  either  a  terminal  or  computer  link.  The  Central  LGN  would  extract  the 
required  data  from  LGN  data  bases  (and  from  user  data  bases  if  required)  and  would 
respond  to  the  query.  Procurement,  stock  status  (wholesale  and  retail),  and  pipeline 
data  would  be  available  in  the  fully  developed  network. 

2.2.3  Joint  Requirements 

Of  particular  interest  is  the  LGN’s  potential  for  providing  a  basis  for  resolution 
of  a  long-standing  requirement  for  improvements  in  the  S/A’s  capability  to  support 
Joint  requirements  for  logistics  information.  These  requirements  stem  from  both 
the  planning  and  execution  responsibilities  of  the  Joint  community. 

Many  existing  and  evolving  systems  in  the  S/As  and  at  the  Joint  level  address 
these  problems.  All  are  hampered  to  some  degree  by  the  lack  of  firm  requirements 
and  standard  data.  Both  of  those  problems  are  being  addressed  in  the  development 
of  the  Joint  Operations,  Planning,  and  Execution  System  (JOPES)  and  its  various 
components,  such  as  the  Joint  Deployment  System  (JDS),  as  well  as  by  internal  S/A 
programs. 

The  LGN  architecture  will  provide  a  basis  for  development  of  capabilities  to 
meet  many  of  the  known  and  potential  Joint  requirements.  To  provide  the  required 
capabilities,  changes  in  traditional  Joint  procedures  may  have  to  be  considered.  For 
example,  planners  will  have  to  project  resupply  requirements  in  terms  of  Federal 
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Supply  Class  (FSC)  and  Subclass  in  lieu  of  the  classes  and  subclasses  currently  used, 
and  critical  items  requirements  may  have  to  be  projected  in  terms  of  National  Stock 
Numbers  (NSNs).  If  those  changes  are  made,  capabilities  based  on  the  LGN 
architecture  would  readily  track  the  flow  of  supplies  during  execution  of  a  crisis/war 
plan. 

Most  of  the  Joint  logistics  information  requirements  appear  to  stem  from  the 
supply  and  transportation  functional  areas.  We  suggest  that  priority  be  given  to 
providing  capabilities  in  those  areas  in  the  development  of  the  Joint  interfaces  with 
MODELS.  Joint  requirements  in  other  functional  areas  can  be  added  later. 

2.2.4  Support  of  Deployed  Forces 

The  basic  purpose  of  MODELS  is  to  provide  a  framework  for  continued 
modernization  of  all  the  logistics  systems  in  DoD.  While  the  DLSS  support  all  U.S. 
forces,  the  support  of  deployed  forces  is  of  particular  concern.  LGNs  to  support 
peacetime  deployments  are  included  in  the  list  of  proposed  LGNs  discussed  later  in 
this  section. 

The  extension  of  DLSS  to  an  undeveloped  area  of  operations  during  a  crisis  or 
mobilization  requires  further  study.  Development  of  the  capability  is  not  expected  to 
be  technically  difficult;  however,  it  will  require  a  great  deal  of  coordination  and  may 
have  to  include  various  options  to  fit  specific  plans.  Two  alternatives  provide  a  point 
of  departure  for  consideration: 

•  Extension  of  S/A  systems  into  undeveloped  theaters.  Under  this  concept, 
logistics  data  would  enter  DLSS  through  existing  LGNs. 

•  Deployment  of  LGNs  with  the  force.  Under  this  concept,  the  deployed 
LGN(s)  would  operate  in  a  similar  manner  to  all  other  LGNs  using  avail 
able  communications  channels. 

2.2.5  Operating  Concept 

The  operations  described  in  the  preceding  examples  are  similar  to  those  per 
formed  by  DAAS,  except  that  the  LGNs  are  physically  located  at  the  same  facility  as 
the  primary  user's  computer  with  which  they  communicate.  As  a  result,  the 
requisition  enters  the  primary  communications  system  a  single  time,  rather  than 
being  transmitted  from  the  source  to  DAAS  and  then  from  DAAS  to  the  Inventory 
Control  Point  (ICP). 
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If  the  transmitting  computer  has  not  been  updated  to  reflect  a  recent  change  in 
requisition  formats  (such  as  the  introduction  of  weapons  coding  data),  the 
transmitting  LGN  requests  the  information  from  the  user's  computer  and  inserts  it 
into  the  correct  DLSS  specified  field  before  it  is  sent.  The  additional  required 
information  is  inserted  using  either  supplementary  file  data,  direct  operator  input, 
or  dummy  codes.  As  a  result,  all  logistics  traffic  would  enter  the  data  communi 
cations  system  in  a  common  DLSS  format.  Similarly,  if  the  receiving  LGN  is 
installed  at  a  site  that  cannot  accommodate  a  recent  DLSS  change,  it  would  reformat 
the  received  data  for  compatibility  with  its  processor,  before  passing  it  to  the 
primary  user  computer. 

The  LGNs  are  also  able  to  process  single,  discrete,  on-line  queries  about  supply 
system  status,  as  illustrated  in  Figure  2-3.-  Responses  are  provided  through  query 
into  the  LGN’s  data  base  through  a  transaction  generated  by  the  LGN  into  the  data 
base  of  the  supported  user  computer.  For  example,  a  requisitioner  wishing  to  inquire 
about  the  status  of  a  particular  requisition  would  enter  the  query.  The  user's 
computer  would  forward  the  query  to  its  local  LGN  as  a  standard  ’'query” 
transaction  using  the  user's  format.  The  local  LGN  would  search  its  own  records  to 
determine  where  the  requisition  had  been  sent  and  would  then  automatically 
forward  a  query  (using  a  standard  DLSS  transaction  format)  to  the  LGN  at  the 
receiving  site.  The  receiving  LGN  would  search  its  data  base  to  determine  whether 
it  processed  any  transactions  related  to  the  requisition.  If  it  had,  it  would  respond  to 
the  inquiring  LGN.  If  the  receiving  LGN  had  no  record  of  further  processing  of  the 
requisition,  it  would  return  a  transaction  to  the  sending  LGN  to  indicate  it  had  no 
further  updates  on  the  requisition  status. 

If  the  receiving  LGN  responds  with  information  indicating  that  the  requisition 
has  been  passed  to  another  site  or  has  entered  the  transportation  system,  the 
inquiring  LGN  would  have  the  capability  to  formulate  additional  queries  for  other 
sites  to  which  the  requisition  response  responsibility  has  been  passed.  In  this 
manner,  the  LGN  at  the  site  of  the  original  query  can  track  the  requisitioned 
materiel  status  throughout  the  logistics  system  through  a  "chained  query"  of  other 
LGNs. 
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FIG  2-3  SIMPLE  VIEW  OF  USER  QUERY  FUNCTIONS 


This  search  process,  combined  with  the  ability  to  formulate  standard  queries 
for  the  user  computer's  data  base,  offers  a  powerful  capability  for  logistics  customers 
to  readily  obtain  up-to-date  information  on  the  status  of  requisitions  without  using 
multiple  terminals  or  waiting  for  printed  reports  to  be  delivered.  Other  query 
capabilities  related  to  system  performance,  item  availability,  transportation 
movement  status,  and  contract  status  will  be  provided.  Simple  queries  will  be 
transmitted  between  LGNs  using  a  common  DLSS  transaction  format.  Complex 
queries  or  nonstandard  queries  must  be  processed  by  the  Central  LGN. 

2.2.6  Logistics  Gateway  Node  Locations 

The  major  logistics  facilities  that  are  candidates  for  LGN'  installation  are 
identified  in  Table  2-1.  That  table  also  identifies  the  presence  of  a  Central  LGN  at 
the  existing  DAAS  site  at  Gentile  Air  Force  Station  in  Dayton,  Ohio.  The  Central 
LGN  would  provide  management  and  updating  for  all  tables,  applications  software, 
and  data  bases  installed  at  the  remote  LGNs.  It  also  would  perform  interfacing, 
reporting,  and  media  conversion  functions.  Table  2-1  indicates  that  LGNs  could  be 
installed  in  CONUS,  Europe,  and  the  Pacific.  Although  Outside  of  the  Continental 
United  States  (OCONUS)  sites  are  not  specifically  identified,  three  installations 
could  be  located  in  the  Pacific  theater  and  three  in  Europe. 

The  facilities  identified  in  Table  2-1  were  selected  on  the  basis  of  the  functions 
they  perform,  the  existing  levels  of  logistics  communications  traffic,  and 
geographical  location.  All  facilities  performing  wholesale-level  logistics  functions 
have  been  included  on  this  list  without  considering  their  existing  communications 
traffic  levels. 

The  number  of  retail  facilities  to  be  included  on  this  list  was  determined  on  the 
basis  of  levels  of  logistics  communications  traffic  levels.  Those  facilities  are  all 
characterized  by  traffic  levels  in  excess  of  I  million  transactions  per  month. 

The  LGN  architecture  includes  provision  for  the  LGN  to  support  nearby 
facilities.  Security  requires  that  communications  with  nearby  facilities  be  per 
formed  using  telecommunications  services  that  can  verify  the  Communications 
Routing  Identifier  (COMM  RI)  of  the  source.  That  restriction  would  permit  the  use 
of  the  DDN,  Automatic  Digital  Network  (AUTODIN),  Inter-S  A  Automated  Message 
Processing  Exchange  (I-S/A  AMPE),  Defense  Logistics  Telecommunications  Net 
work  (DLANET),  Stock  Point  Logistics  Integrated  Communications  Environment 


TABLE  2-1 
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CANDIDATE  LOGISTICS  GATEWAY  NODE  LOCATIONS 


Facility  type 

Organization 

Number  of 
locations 

•  | 

Detense  Contract  Administration 
Service  Regions  (DCASRs) 

ICPs 


Depots  not  collocated  with  ICPs 


Defense  Reutilization  and 
Marketing  Service  (DRMS) 

Cataloging  [Defense  Logistics 
Service  Center(  DLSC)] 

Defense  Transportation  System 
(DTS) 


Central  LGN  (Dayton,  Ohio) 
Service  finance  centers 


Major  CONUS  retail  facilities 
(locations  to  be  determined) 

International  Logistics  Control 
Offices  (ILCO) 


European  Theater 
Pacific  Theater 
JOPES 

LGNs  could  also  be  installed  at  the 
sites  of  commercial  organizations 


Army 
Navy 
Air  Force 
Marine  Corps 
DLA 

General  Services  Administration  (GSA) 

Army 

Navy 

Marine  Corps 
DLA 

DLA  -  Battle  Creek,  Michigan 


Army  [Military  Traffic  Management 
Command  (MTMC)] 

Navy  [Military  Sealift  Command  ( MSC) ] 
Air  Force  [Military  Airlift  Command 
(MAC)] 


Army 
Navy 
Air  Force 
Marine  Corps 

All  Services 


Shared  facilities 
Shared  facilities 
OJCS 


Collocated 
with  other 
Service 
facilities 

3 

3 


to  be 

determined 


0 


1 


(SPLICE),  Marine  Corps  Data  Network  (MCDN).  etc.  Leased  lines  could  also 
provide  this  capacity.  While  the  use  of  commercial  dial-up  telephone  facilities  is 
technically  feasible,  it  precludes  verification  of  the  origin  of  the  sender,  a  function 
that  is  required  to  prevent  unrestricted  access  to  the  system. 


2.2.7  Local  Site  Configuration 


In  a  typical  configuration,  the  LGN  would  act  as  an  interface  between  the 
user's  processor  and  a  communications  service  such  as  DDN.  Logistics  traffic 
originating  at  the  user’s  computer  would  be  transmitted  to  the  LGN  using  the  data 
formats  of  the  user's  configuration.  The  LGN  would  receive  the  user  transmission, 
identify  the  destination  address(es),  and  translate  the  user’s  data  formats  into  a 
common  DLSS  format  before  transmitting  the  data.  In  addition,  the  LGN  would 
perform  necessary  table  maintenance  and  accumulation  of  traffic  statistics.  The 
LGN  at  the  destination  facility  would  receive  the  data  and  translate  it  into  the 
language  used  by  the  user  at  the  destination  site.  The  general  equipment  config¬ 
uration  to  support  this  operation  is  shown  in  Figure  2-4. 


2.2.8  Common  Defense  Logistics  Standard  Systems  Formats 


The  processing  sequence  defined  above  permits  the  use  of  unique  data  formats 
by  the  user’s  equipment  while  ensuring  that  all  logistics  data  are  transmitted  using 
a  common  DLSS  format.  The  DLSS  formats  will  be  designed  to  accommodate 
Service-unique  fields.  This  approach  permits  the  use  of  differing  user  data  formats 
that  will  be  invisible  to  the  overall  logistics  system  because  of  the  translation 
capability  of  the  LGN.  As  a  result,  DLSS  changes  can  be  implemented  without  the 
delays  that  are  currently  imposed  when  a  single  Service  is  unable  to  quickly 
implement  the  required  modification. 


The  significance  of  this  capability  should  not  be  underestimated.  In  general,  a 
DLSS  change  requires  between  1  and  2  years  for  its  implementation.  This  delay  is 
necessary  because  of  the  need  to  delay  system  revisions  until  all  participating 
organizations  are  able  to  update  their  user  software  in  response  to  the  required 
DLSS  change.  These  delays  are  currently  increasing  because  of  Service  requests 
that  changes  be  delayed  as  long  as  possible  to  avoid  disrupting  ongoing  moderni 
zation  programs.  However,  requirements  for  future  DLSS  changes  will  probably 
occur  at  an  increasing  rate  because  of  the  introduction  of  new  requirements  and 
capabilities  such  as  transmission  of  graphics  information,  on-line  data  base  queries 


(processed  as  standard  query  transactions),  and  increasing  mission  and  equipment 
complexity.  Thus,  it  is  important  that  the  DoD  logistics  system  be  able  to  rapidly 
accommodate  new  information  interchange  requirements. 

2.2.9  Standard  Design  Configurations 

The  widespread  installation  of  LGNs  requires  that  they  be  economical  to 
purchase,  operate,  and  maintain.  If  these  nodes  are  permitted  to  become  major  data 
processing  installations,  the  LGN  architecture  will  not  be  cost  effective.  Thus,  the 
viability  of  the  concept  requires  that  the  design  of  the  individual  nodes  be  as  simple 
as  possible.  To  achieve  that  objective,  standardized  configurations  tailored  to  the 
category  of  facilities  supported  have  to  be  developed.  A  series  of  standard  configura¬ 
tions  that  will  satisfy  the  requirements  of  user  sites  is  listed  in  Table  2-2.  These 
standard  configurations  were  selected  on  the  basis  of  differences  between  their  user 
configurations  (both  existing  and  planned).  In  defining  these  configurations,  it  is 
assumed  that  the  Services  and  DLA  will  provide  standardized  systems  within  each 
functional  level  of  their  own  operation  (e.g.,  ICP,  depot,  retail  level). 

While  it  appears  that  the  support  of  the  standard  configurations  listed  in 
Table  2-2  could  lead  to  configuration  management  problems,  it  is  important  to 
recognize  that  the  differences  between  these  configurations  is  restricted  to  their 
translation  of  formats  between  the  user’s  processor  and  the  DLSS  standard  formats. 
The  other  difference  will  be  in  their  ability  to  provide  the  Service  unique  processing 
required  by  the  Service  of  the  user's  site.  Since  this  is  a  relatively  small  percentage 
of  the  overall  processing  performed  by  the  LGN.  the  support  of  multiple  configura 
tions  is  significantly  simplified.  Further  simplification  can  be  provided  using 
"table  driven  logic”  to  provide  the  necessary  translation  functions.  Such  logic  will 
permit  revision  of  format  translation  features  through  data  base  updates  rather  than 
software  programming  modifications. 

2.2.10  Configurations 

The  LGN  will  be  designed  to  permit  transmission  of  tables,  application  soft 
ware  machine  code,  and  data  base  updates  from  a  central  site.  With  that  capability, 
all  processors  can  be  managed  by  a  central  design  and  programming  organization 
and  access  to  data  collected  by  the  LGN  will  be  centralized.  The  ability  to  manage 


TABLE  2-2 

STANDARD  LOGISTICS  GATEWAY  NODE  CONFIGURATIONS 


Organization 

LGN  configurations 

Army 

Wholesale 

Retail 

Navy 

Wholesale 

Retail 

Air  Force 

Wholesale 

Retail 

Marine  Corps 

Wholesale 

Retail 

GSA 

Single  IGN 

DIA 

i 

| 

Central  LGN 

Wholesale 

DCASR 

DLSC 

DRMS 

Transportation  Operating 

Agencies 

(MTMC,  MAC,  MSC) 

Transportation 

■  OJCS 

1 

Worldwide  Military  Command  and  Control  System 
(WWfMCCS)  information  System  (WiS) 

the  LGN  from  a  central  site  minimizes  the  operations  and  maintenance  staff 
required  at  the  individual  logistics  site. 

2.2.1 1  Comparison  with  Existing  Architecture 

While  some  of  the  LGN’s  processing  is  similar  to  that  performed  by  the  existing 
DAAS  facilities,  the  following  significant  differences  also  exist  between  the  two 
architectures: 

•  The  LGNs  are  not  identical  but  rather  are  tailored  to  meet  the  requirements 
of  the  site  at  which  they  are  installed.  This  approach  results  in  an  LGN  pro 
cessing  load  significantly  less  than  that  experienced  by  the  DAAS  sites 
serving  the  entire  logistics  community. 

•  The  LGN  is  designed  to  be  responsive  to  the  format  translation  require 
ments  of  the  individual  user's  computer  system  served.  The  translation 
process  will  include  such  actions  as  adding  fields,  deleting  fields,  changing 
field  lengths,  merging  data  from  multiple  sources,  etc.  It  would  not  include 


translations  between  computer  languages  involving  complex  analysis  of  the 
data  contents  of  a  message. 


•  The  LGX  architecture  ensures  that  all  logistics  data  transmitted  from  the 
LGX  are  in  common  DLSS  format.  Use  of  a  common  transmission  format 
eliminates  the  complexity  of  the  multiple  translations  that  would  be 
required  to  provide  compatibility  between  all  combinations  of  transmitting 
and  receiving  systems. 

•  While  a  tariff  has  not  yet  been  established  for  the  use  of  the  DDX.  users  of 
this  system  will  probably  be  charged  for  data  transmission  services  in  the 
near  future.  Data  communications  tariff  structure  is  typically  a  function  of 
both  the  number  of  data  transmissions  and  the  amount  of  data  transmitted. 
The  DAAS  architecture  requires  duplicate  transmission  of  all  data  (once 
from  the  origin  to  DAAS  and  a  second  time  from  DAAS  to  the  destination). 
The  LGX  data  traffic  enters  the  DDX  a  single  time  since  it  is  transmitted 
directly  from  origin  to  the  destination. 

•  The  existing  DAAS  architecture  is  designed  to  function  as  a  highly  cen 
tralized  system.  All  logistics  data  collected  by  DAAS  are  centrally  stored. 
Performance  reports,  requests  for  requisition  status,  etc.,  can  only  be 
provided  if  they  are  available  in  the  large  central  data  base.  The  LGX 
architecture  is  a  distributed  architecture  in  which  the  data  used  for  prepar 
ing  reports  and  responding  to  queries  are  stored  at  the  originating  site. 
This  architecture  requires  the  use  of  a  distributed  data  base  management 
system  (DDBMS)  that  formulates  queries  and  directs  them  to  remote  sites. 

2.3  DATA  BASE  MANAGEMENT 
2.3.1  Background 

The  proposed  LGX  network  will  consist  of  computers  connected  by  one  or  more 
communication  systems  and  supported  by  a  homogeneous,  relational  DDBMS.  In  a 
homogeneous  DDBMS,  each  computer  in  the  network  supports  the  same  data  base 
management  system  (DBMS).  Each  computer,  however,  has  DBMS  and  communi 
cations  software.  The  communications  software  performs  the  data  exchange  func 
tion  between  the  user,  local  computer,  and  the  LGX.  The  DBMS  manipulates 
the  separate  data  bases  stored  in  LGXs  that  are  linked  in  the  network.  Since  data 
distribution  is  transparent  to  the  user,  '  any  data  in  the  network  can  be  accessed 
without  havi ng  to  know  where  those  data  are  stored. 
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Distributed  data  bases  can  increase  performance  since  the  load  can  be  shared 
among  processors  to  allow  parallel  operations.  Data  concurrency  -  or  keeping 
several  copies  of  the  same  data  current  —  requires  complex  algorithms  to  synchro 
nize  data  updates.  In  addition,  a  DDBMS  must  maintain  a  conceptual  or  overall 
view  of  the  data  in  the  network.  This  requires  a  data  dictionary  directory  (DD  Do 
discussed  in  the  next  section,  to  keep  track  of  data  locations. 

The  data  and  tables  will  be  distributed  across  the  network  in  a  pattern 
determined  by  operational  needs,  performance  requirements,  and  availability.  The 
user  will  interact  with  the  data  base  using  transactions  to  distributed  programs  that 
will  run  simultaneously  at  multiple  nodes  and  synchronize  their  processing  by 
exchanging  messages. 

DDBMS  software  is  needed  to  offer  improved  services  to  DLSS  users.  A 
number  of  files  are  currently  maintained  for  the  codes,  tables,  addresses,  and  other 
stored  data  elements  used  in  routing  and  other  functions  performed  by  DAAS.  The 
data  files  will  be  altered  by  on-line,  low- volume  updates  and  by  batch  large-scale 
updates.  In  the  flat-file  structure  used  today,  it  is  necessary  to  keep  the  data  in 
multiple  file  copies  to  support  different  access  requirements.  The  use  of  DDBMS 
software  will  support  multiple-access  methods,  as  well  as  provide  rapid  search  and 
retrieval  of  those  data  without  requiring  multiple  files.  A  DDBMS  will  also  provide 
security  for  key  documents,  addresses,  and  routing  data.  Use  of  a  DDBMS  will 
improve  physical  access  to  the  data,  consolidate  update  procedures,  and  provide 
standardization  of  data  elements. 

The  major  reporting  functions  provided  by  DAAS  today  will  be  augmented  by 
improved  ad  hoc  reporting  and  on-line  information  query  capabilities  to  support  user 
requests  for  data  collected  and  maintained  by  the  LGNs.  The  DDBMS  software  will 
provide  for  the  rapid  retrieval  of  data  in  response  to  an  ad  hoc  query  or  report 
request.  An  ad  hoc  reporting  capability  must  accommodate  individual  Service 
requirements. 

A  critical  design  factor  will  be  the  partitioning  of  functions  between  the  centra! 
facility  and  the  local  LGNs.  Distribution  of  data  processing  and  data  storage  is 
characterized  by  the  fact  that  some  data  may  be  maintained  centrally,  some 
remotely,  and  some  may  be  common  to  both  central  and  remote  sites.  Before  a  final 
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decision  is  made  on  the  actual  distribution  of  functions  and  data,  a  number  of  factors 
must  be  considered  in  evaluating  a  DDBMS,  including: 

•  System  architecture  —  how  do  the  major  transaction  flows  translate  into 
logical  functions  to  be  performed  and  where  will  the  source  user  functions 
be  located? 

•  Technical  resources  —  how  should  the  DAAS  logical  functions  be  distrib 
uted.  sourced,  and  implemented  in  terms  of  specific  physical  components? 

•  Management  control  —  what  techniques  are  needed  to  plan,  implement, 
and  maintain  changes? 

•  Organization  —  to  what  extent  does  the  redistribution  of  human  and  tech 
nical  information  resources  require  a  redistribution  of  .organizational 
responsibilities? 

2.3.2  Data  Query  Requirements 

A  user  views  the  LGN  network  in  two  ways.  Most  users  will  access  the  local 
computer  and  perform  the  usual  activities,  and  the  local  computer  will  generate 
transactions  to  be  sent  to  the  LGN.  A  user  may  also  perform  a  query  or  generate  an 
ad  hoc  report.  In  those  cases,  the  user  will  either:  ( 1)  enter  a  command  on  the  local 
computer  that  submits  a  request  to  the  local  LGN  for  a  pass-through  to  either  the 
Central  LGN  or  the  remote  LGN  containing  the  requested  data,  and  the  query 
function  will  simply  appear  to  be  another  function  that  is  supported  on  the  user's 
computer;  or  (2)  for  complex  or  global  queries  and  ad  hoc  reports,  call  directly  into 
the  Central  LGN.  Both  procedures  are  depicted  in  Figure  2  5. 

When  the  user  wants  to  submit  a  series  of  queries  or  knows  that  certain 
requests  generally  have  a  slow  response  time,  the  query  may  be  submitted  as  a  batch 
request.  The  user’s  system  will  inform  the  user  when  the  query  request  has  been 
accepted.  The  user  may  then  format  another  query  or  terminate  the  session.  The 
user  will  be  notified  when  the  response  is  ready,  or  the  user  may  request  the  status  of 
jobs  either  in  the  current  session  or  in  a  later  session.  The  user  may  then  retrieve 
the  jobs. 


1  '  1 


r\- 


V  VV  -  -  V 


LhAi 


* 


A.  V.  v 


il 


Authorized  personnel 


Satellite 

user 


FIG.  2-5.  SIMPLE  VIEW  OF  NETWORK  DATA  QUERY  FUNCTIONS 

To  allow  users  maximum  flexibility  in  accessing  the  data  base  and  to  allow 
f  them  to  easily  express  both  simple  and  complex  data  retrieval  operations,  an 

English-like  query  language  will  be  provided.  In  addition,  the  query  facility  will  be: 

•  Interactive 

•  Supportive  with  interactive  display  of  the  data  dictionary,  prompts,  HELP 
messages,  query,  and  modification  status  displays 

•  User-oriented,  i.e.,  can  be  used  by  non-ADP-oriented  users  with  a  minimum 
of  instructions 

•  Nonprocedural,  i.e.,  users  will  only  need  to  specify  what  is  wanted  and  not 
how  to  search  the  data  base  to  obtain  it,  nor  how  to  display  the  results. 

The  query  language  will  provide  the  capability  for  an  on-line  user  to  request  that  a 
query  be  executed  on-line  (interactively)  with  results  available  on-line  or  to  be 
executed  in  batch  mode  with  results  available  upon  request.  The  DBMS  capability 
may  permit  user-defined  query  formats  and  query  results  to  be  named  and  stored  for 
later  use. 
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A  report  generator  will  provide  users  with  capabilities  to  produce  simple  or 
complex  hierarchical  reports  in  user-specified  formats  by  directly  accessing,  through 
the  Central  LGN,  the  LGN  data  base  files  in  which  responses  to  queries  are  stored. 
The  report  generator  will  be  compatible  with  the  DDBMS  and  can  access  data 
records  or  query  results  files.  It  also  will  offer  users  the  capability  to  produce  reports 
in  batch  mode.  Immediately  after  completion  of  processing,  the  results  of  batched 
reporting  requests  can  be  made  available  to  the  user’s  host  on  the  LGN  network. 

2.3.4  Data  Dictionary/Directory 

The  integration  of  data  base  technology  into  a  network  environment  leads  to 
the  need  for  new  functions  and  capabilities,  as  outlined  in  Table  2-3.  Information 
must  be  supported  at  both  the  network-wide  level  and  at  the  individual  LGN  level. 
Figure  2-6  depicts  a  possible  dictionary/directory  architecture  for  the  proposed 
network.  The  network  data  directory  provides  network-wide  knowledge  of  the  node 
location  of  all  the  data  bases  in  the  system,  specifying  any  partitioning  of  data  across 
multiple  nodes  and  any  data  replication  between  nodes.  Complementing  the 
network  data  directory  is  the  network  data  dictionary,  which  contains  information 
on  the  types  and  formats  of  the  various  data  bases  and  the  data  elements  contained 
in  each. 

Combined,  and  possibly  residing  at  each  node,  a  data  dictionary/directory 
subsystem  (DD/DS)  capability  may  serve  as  the  master  index  (analogous  to  a  card 
catalog  in  a  library)  through  which  authorized  users  may  be  introduced  to  the 
various  systems  and  services;  the  types,  formats,  and  location  of  available  data 
bases;  and  the  procedures  to  be  followed  for  gaining  access  to  the  data.  The  purpose 
of  the  DD/D,  therefore,  is  simply  to  let  users  know  what  systems,  services,  and  data 
are  available  at  other  nodes. 

A  directory  system  may  be  organized  in  several  ways.  A  centralized  directory 
is  stored  on  only  one  system  and  has  a  conceptual  view  of  the  data  entities  in  all  the 
DBMSs.  An  extended  directory  maintains  local  information  from  the  centralized 
directory.  Whenever  a  site  requests  the  location  of  data  from  the  centralized 
directory,  the  local  site  copies  the  information  into  its  own  extended  directory  so  it 
does  not  have  to  request  the  location  again.  A  local  directory  provides  only  that  data 
relating  to  the  site’s  DBMS.  In  a  distributed  directory  system,  each  computer  has  a 


TABLE  2-3 


FUNCTIONS  AND  CAPABILITIES  TO  SUPPORT  A  NETWORK  ENVIRONMENT 


At  a  central  location 

Functions 

Network  data  directory 

Maintains  control  information  on  node 
location  of  data  bases  and  data  base 
positions. 

Network  data  dictionary 

Contains  information  on  types  and 
formats  of  the  various  data  bases  and  the 
data  elements  contained  in  each. 

Residinq  at  each  node 

Data  dictionary/directory 

Serves  as  an  index  to  systems,  services, 
types,  formats,  and  location  of  data  bases. 
Contains  procedures  for  data  base  access 
as  required  by  users  at  a  particular  node 

Network  data  base  management  system 

Services  global  data  base  requests  for 
users  at  one  particular  node 

complete  copy  of  the  central  directory.  Performance  tradeoff  studies  must  be 
performed  to  determine  the  best  approach  for  the  proposed  LGN  architecture. 

In  conjunction  with  the  DD/D,  a  DDBMS  is  necessary  at  each  node  to  service 
the  users’  global  data  base  requests.  The  DDBMS  links  the  user,  the  local  DBMS, 
the  directory  of  data  stored  in  the  local  DBMS,  and  the  network.  If  we  assume  a 
DBMS  only  includes  those  functions  that  relate  to  a  local  data  base  and  that  it  has  no 
knowledge  of  any  other  data  node,  then  all  the  other  data  base  management 
functions  needed  in  a  distributed  network  environment  have  to  be  subsumed  by  the 
DDBMS.  The  DDBMS  should,  therefore,  serve  the  following  functions: 

•  Intercept  a  user  request  and  determine  where  to  send  it  for  processing,  or 
what  nodes  must  be  accessed  to  satisfy  it 

•  Access  the  DD/D  or  at  least  know  how  to  request  and  use  the  information 
in  it 

•  Coordinate  the  processing  and  response  to  a  user  request  if  it  spans  nodes, 
that  is,  if  the  target  data  exists  at  multiple  nodes 


SOFTWARE  COMPONENTS  OF  THE  LOGISTICS  GATEWAY  NODE  ARCHITECTURE 


•  Function  as  the  communications  interface  among  the  user  process,  the  local 
DBMS,  and  DBMSs  at  other  nodes 

•  Provide  data  and  process  translation  support  in  a  heterogeneous,  distrib 
uted,  data  base  environment. 

Support  utilities  provide  the  Data  Base  Administrator  (DBA)  with  the  tools  to 
assist  in  gathering  the  detailed  information  and  descriptions,  validating  the  data 
base  entries,  establishing  system  security  information,  and  maintaining  and  testing 
the  dictionary/directory  entries  required  by  the  system. 4  The  DDBMS  should 
provide  easy-to-use,  easy-to-maintain,  on-line  access  to  the  data  base  definitions 
(i.e.,  unique  identifiers,  physical  characteristics,  and  textual  descriptions  of  data 
elements,  etc.). 

The  local  data  dictionary  should  have  the  following  set  of  basic  characteristics: 

•  Contain  unique  identifiers,  physical  characteristics,  and  textual  informa¬ 
tion  for  each  data  element 

•  Show  the  relationships  between  elements  (i.e.,  the  model  or  schema  rela¬ 
tionship  specification  for  each  data  element  in  the  data  base) 

•  Be  treated  by  the  DBMS  the  same  as  other  data  in  the  data  base  (e.g., 
capable  of  being  queried) 

•  Be  integrated  within  the  DBMS 

•  Contain  the  official  external  name  and  acceptable  synonyms  for  each  data 
element 

•  Use  rules  or  algorithms  for  data  elements  that  are  computed  from  the 
values  of  other  data  elements 

•  Use  keying  designations  (e.g.,  whether  the  element  is  a  unique  primary 
key,  is  unkeyed,  etc.) 

•  Use  statistical  information  such  as  journalizing  information  describing 
system  or  environment  interfaces;  frequency  of  access,  update,  and  archiv¬ 
ing;  usage  statistics;  performance  statistics,  log,  and  audit  information 

•  Use  system  security  information  such  as  authority  and  date  authorized, 
owner  information,  version  of  this  entity,  edit  and  validation  criteria. 


'The  DBA  function  is  located  at  the  Central  I,GN 


The  National  Bureau  of  Standards  (NBS)  Information  Resource  Dictionary 
System  (IRDS)  specifications  should  be  considered  in  the  procurement  or  develop 
ment  of  a  DD/D.  The  IRDS  specifications  are  a  draft  proposed  American  National 
Standards  Institute  (ANSI)  standard,  a  draft  proposed  U.S.  Federal  Information 
Processing  Standard  (FIPS),  and  a  Working  Document  of  the  International  Stan¬ 
dards  Organization  (ISO),  Subcommittee  21,  Working  Group  3. 

2.3.5  Variable-Length  Records  and  Service-Unique  Data 

Variable-length  transactions,  i.e.,  those  with  variable  field  lengths  and  vari¬ 
able  fields  allow  a  user  to  limit  transaction  lengths  to  the  amount  of  information 
necessary  without  sending  blank  spaces.  With  variable  field  lengths,  character 
positions  are  not  important;  the  field  position  is  the  important  characteristic. 

A  number  of  alternative  approaches  are  possible  for  the  implementation  of 
variable-length  transactions.  One  alternative  is  the  position-dependent  format,  in 
which  fields  are  identified  by  their  sequence  in  the  message.  In  that  format,  fields 
are  separated  by  a  unique  character  such  as  an  asterisk  and  the  omission  of  a  field  is 
designated  by  two  adjacent  asterisks.  A  second  alternative  is  the  use  of  field  desig¬ 
nators,  which  precede  the  field  to  identify  its  purpose. 

The  EDI  standard  proposed  for  commercial  transportation  activities  by  the 
Transportation  Data  Coordinating  Committee  (TDCC)  in  1975  offers  a  hybrid 
approach  to  the  implementation  of  variable-length  transactions.  This  standard 
defines  transactions  using  a  multilayer  organization  made  up  of  segments  and  fields. 

Segments  are  equivalent  to  the  contents  of  a  line  or  box  on  a  form.  For 
example,  they  might  include  the  geographic  location  of  the  originator  of  a  requi 
sition. 

The  fields  that  make  up  a  segment  are  presented  in  a  fixed  sequence.  For 
example,  in  a  geographic  location  segment,  the  city  name  must  precede  the  state 
code.  The  absence  of  a  data  element  (e.g.,  the  location  qualifier)  is  designated  by  an 
adjacent  asterisk  (*). 

The  EDI  standard  does  not  define  a  fixed  format.  It  represents  an  overall 
approach  that  can  be  adapted  to  the  requirements  of  a  specific  user  or  industry.  It  is 
being  adopted  by  a  broad  range  of  foreign  and  U.S.  industries  as  a  data  exchange 
standard,  including  many  of  the  industries  with  which  the  DoD  logistics  system 


must  interface.  For  these  reasons,  we  recommend  that  the  EDI  standard  be  adopted 
in  concept  by  DoD  for  the  design  of  future  DLSS  transactions. 


Information  will  be  derived  from  the  various  Services'  data  description 
manuals  to  determine  which  Service-specific  data  elements  must  be  translated  to  the 
DLSS  standards.  Data  element  standards  include  standard  coding  formats  for 
enumerated  sets  (e.g.,  state  names),  uniform  reference  number  assignments  to  lists 
of  values,  and  DoD- wide  standard  naming  conventions  and  codes. 

A  table-driven  technique  will  generalize  processing  regardless  of  the  applica¬ 
tion  being  handled.  Data  element  modifications  then  simply  require  a  change  to  a 
table.  The  DLSS  standards  will  accommodate  maximum  data  element  lengths  for  all 
the  Services.  Differences  between  the  standard  length  and  the  length  expected  by 
the  receiving  Service  will  be  accommodated  through  table  manipulation.  The 
software  will  take  a  user’s  fixed  format  record,  edit  it  according  to  the  DLSS 
standards,  and  construct  transactions  for  transmission.  The  receiving  LGN  will 
perform  the  opposite  function  to  reformat  data  into  the  required  local  computer’s 
receiving  format. 

2.3.6  Configuration  Management 

A  critical  factor  in  the  LGN  software  and  data  base  implementation  and 
maintenance  is  control  of  changes  to  the  system  design.  Controls  must  be  rigorously 
enforced  to  prevent  unauthorized  or  undocumented  changes.  User  changes  must  be 
restricted  to  the  Central  LGN  software  development  and  maintenance  team,  and 
reconciliation  of  design  errors  discovered  during  the  programming/coding/testing 
process  must  follow  defined  procedures. 

Configuration  management  establishes  the  disciplined  environment  needed  to 
implement  these  controls  for  maintenance,  testing,  and  redeployment  of  applications 
software,  as  well  as  procedures  for  updating,  testing,  and  redeploying  the  DD/D  data 
bases.  Configuration  management  should  include  procedures  for: 

•  Positive  identification  and  library  listing  of  all  program  components 
(modules) 

•  Rapid,  comprehensive,  and  accurate  processing  of  proposed  changes 

•  Complete  implementation  of  approved  changes  and  dissemination  of 
corrected  documentation  and  program  changes 


•  Accurate  records  of  status  of  all  proposed  changes 

•  Verification  of  change  control,  identification,  and  status  accounting  of  the 
descriptive  documentation  and  program  materials. 

2.3.7  Security  and  Data  Integrity 

The  DBMS  provides  the  interface  between  individual  application  software  and 
specific  data  items  in  the  data  base.  For  that  reason,  it  is  important  that  DBMS 
security  features  be  implemented  to  provide  security  over  data  base  access  as  well  as 
to  control  the  addition,  modification,  and  deletion  of  data.  Security  functions  are 
provided  for  monitoring  all  DBMS  activities.  Those  functions  include  audit  trails, 
data  base  access  control  through  user  authentication,  procedures  for  identifying 
violations,  and  logging  of  data  base  errors  and  failures.  User  authorization  codes  or 
passwords  are  used  to  control  access  to  data  items  by  file,  record,  data  value,  and 
type.  Security  functions  also  include  maintenance  within  the  DD/D  of  user  access 
lists  associated  with  the  distributed  data  bases. 

In  addition,  hardware  and  system  software  features  should  be  provided  to 
ensure  data  integrity  in  the  processing  and  transmission  of  data.  Three  charac¬ 
teristics  that  constitute  data  integrity  and  that  must  be  maintained  at  all  times  are 
completeness,  validity,  and  consistency.  They  are  maintained  according  to  the 
specifications  in  the  data  definitions  contained  in  the  data  dictionary. 

A  data  distribution  management  function  supports:  (1)  retrieval  of  data  that  is 
not  part  of  a  local  LGN’s  data  base  but  resides  in  data  bases  belonging  to  other  LGNs 
and  (2)  distribution  of  updates  to  other  nodes.  Multiple  copies  of  data  kept  in 
distributed  data  bases  must  be  maintained  in  a  consistent  state  without  causing 
unacceptable  delays  in  processing.  The  data  dictionary  contains  all  specifications  to 
support  the  control  and  integrity  of  the  distribution  of  data.  The  data  distribution 
function  is  responsible  for  ensuring  that  all  updates  to  distributed  data  bases  are 
done  in  a  proper  time  sequence. 

2.4  LOGISTICS  GATEWAY  NODE  FUNCTIONS 

The  current  DAAS  and  the  proposed  LGN  system  architectures  differ,  and  thus 
modifications  to  the  performance  of  some  DAAS  functions  are  required.  Further 
more,  additional  functions  are  needed  to  support  the  recommended  MODELS 
modifications.  The  range  of  LGN  functions  is  described  in  this  section. 


The  LGN  functions  are  grouped  into  five  categories:  ( 1 )  communications. 
(2)  operations.  (3)  document  routing/ passing'editing,  (4)  file  maintenance,  and 
(5)  performance  monitoring. 

2.4.1  Communications/Gateway  Functions 

Communications/gateway  functions  include  all  activities  associated  with  the 
data  communications  process  —  the  translation  of  data  formats  and  protocols,  the 
interface  with  communications  systems,  error  checking,  message  transmission  and 
delivery,  security,  and  interface  with  nearby  installations.  The  following  is  a  list  of 
functions  in  this  category: 

•  Reformatting  between  variable-length  DLSS  format  and  local  user  formats. 

•  Imposing  MINIMIZE  restrictions  on  communications  traffic. 

•  Retransmission  of  lost  documents  or  documents  received  with  errors. 

•  Automatic  back-up  generation  of  all  files. 

•  Automatic  transfer  to  back-up  processor  in  the  event  of  primary  processor 
failure. 

•  Interface  with  DDN,  DAAS,  and  host  electronic  mail  systems. 

•  Receive  and  store  messages  until  they  are  delivered. 

•  Monitor  communications  and  deny  all  invalid  requests  based  on  COMM  RI 
and  DoD  Activity  Address  Code  (DoDAAC).  Monitoring  is  to  be  performed 
both  at  the  origination  and  destination  LGNs. 

•  Interface  with  DDN,  AUTODIN,  I-S/A  AMPE,  and  DLANET  for  DLSS 
communications. 

•  Accept  inputs  from  remote  sites  using  any  military  data  communications 
system  capable  of  verifying  the  location  COMM  RI  of  the  sender  or  from 
leased  lines. 

To  preserve  the  simplicity  of  the  LGN  architecture,  it  is  desirable  to  restrict 
locations  served  by  a  given  LGN  to  the  same  S/A  to  limit  Service-unique  processing 
and  format  translation  requirements.  Otherwise,  program  complexity,  program  and 
table  sizes,  and  hardware  capability  and  capacity  could  severely  limit  the  efficiency 
of  the  LGN  architecture. 


To  ensure  that  the  required  simplicity  is  retained,  locations  that  do  not  have 
their  own  LGN  will  communicate  through  the  nearest  same  S/A  LGN  capable  of 
supporting  their  requirements.  Exceptions  to  this  rule  may  occur  only  when  it  is 
more  convenient  to  install  a  large  LGN  capable  of  supporting  multiple  categories  of 
facilities.  An  example  of  this  situation  may  be  OCONUS  LGN  installations. 

2.4. 1. 1  Communications  System  Interfaces 

This  function  includes  the  capability  of  the  LGN  to  interface  with  the  data 
communications  services  operated  by  DoD,  including  DDN  and  AUTODIN.  In 
addition,  the  LGNs  must  communicate  with  existing  logistics  support  services  such 
as  DLANET,  SPLICE,  and  MCDN,  although  it  is  anticipated  that  those  services  will, 
in  the  future,  make  use  of  DDN  for  their  intra-Service  communications. 

Transactions  from  nearby  facilities  of  the  same  S/A  nearby  facilities  will  be 
processed  by  the  LGNs  in  the  same  manner  as  transactions  received  from  a 
collocated  user’s  processor.  However,  those  transactions  may  be  transmitted  to  the 
LGN  site  either  over  intra-Service  communications  to  the  local  computer  or  over 
direct  leased  lines. 

Protocols  must  be  converted  and  messages  reformatted  in  a  manner  consistent 
with  the  requirements  of  the  transmission  service  being  used,  and  messages  must  be 
transmitted  in  the  appropriate  DLSS  format.  In  terms  of  the  OSI  model  described  in 
Appendix  B  and  shown  in  Figure  2-7,  the  combination  of  the  communications 
protocol  and  DLSS  data  formats  will  completely  define  the  information  interchange 
requirements  of  the  logistics  process. 

2. 4. 1.2  Redundancy  and  Back-Up 

The  LGNs  will  be  designed  for  a  high  level  of  reliability.  All  equipment 
functions  and  message  traffic  will  be  continuously  monitored  for  hardware  malfune 
tion,  software  errors,  and  data  transmission  errors. 

Since  the  reliability  of  the  local  computers  and  communications  interface 
equipment  is  outside  the  control  of  the  LGN,  it  will  be  designed  to  ensure  that 
failures  of  such  equipment  will  not  endanger  the  integrity  of  the  data  being  returned 
to  the  user.  Since  data  integrity  is  a  higher  consideration  than  performance,  queries 
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in  progress  during  failure  situations  may  be  aborted  and  rerun  at  a  later  time  to 
provide  the  required  integrity. 

A  primary  communications  function  of  the  LGN  is  the  updating  of  a  history  file 
in  which  all  transactions  are  archived.  This  function  provides  communications  back¬ 
up  (to  permit  retransmission  of  lost  messages)  and  serves  as  a  data  base  for  perform¬ 
ance  and  status  reporting.  The  archiving  functions  are  described  in  additional  detail 
in  the  File  Maintenance  subsection. 
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Access  security  to  the  LGN  system  is  equivalent  to  that  currently  provided  by 
DAAS.  All  data  traffic  received  at  the  LGN  will  be  checked  to  ensure  that  it 
originates  from  a  source  with  a  valid  COMM  RI  and  a  valid  DoDAAC. 

The  access  security  requirements  of  the  system  will  be  in  full  conformance  with 
the  current  access  protection  (Class  C2)  provisions  of  the  Orange  Book  (the 
15  August  1983  or  later  edition  of  the  DoD  Trusted  Computer  System  Evaluation 
Criteria).  The  C2  or  Controlled  Access  level  of  protection  makes  users  individually 
accountable  for  their  actions  through  log-on  procedures,  auditing  of  security¬ 
relevant  events,  and  resource  isolation.  Computer  security  functional  capabilities 
will  be  provided  to  meet  the  following  categories  of  requirements: 

•  Computer  security  program  management 

•  Personnel  security 

•  Physical  security 

•  Network  security 

•  Data  security 

•  Data  back-up  and  disaster  recovery. 

A  fully  developed  access  security  requirements  analysis  will  be  completed  prior  to 
the  LGN’s  final  specification. 

2. 4.1. 4  Data  Security 

Existing  logistics  data  is  communicated  on  unsecured,  unclassified  lines.  The 
nature  of  individual  pieces  of  logistics  information  is  unclassified.  However,  when 
logistics  data  is  accumulated  and  aggregated,  it  can  result  in  information  that  is  at 
least  "sensitive”  relative  to  national  security,  and  in  some  instances  may  result  in 
classified  data,  particularly  during  a  national  crisis  or  wartime. 

Existing  procedures  require  the  transmission  of  classified  data  directly  from  its 
origin  to  its  destination  over  secured  lines,  bypassing  DAAS.  The  LGN  architecture, 
which  supports  direct  communication  between  origin  and  destination,  could  be 
equipped  with  communications  facilities  and  lines  capable  of  transmitting  classified 
data.  Also,  because  the  LGN  will  already  be  incorporating  translation  capability. 


adding  encryption  capability  would  be  relatively  easy  if  this  requirement  is 
identified  early  in  the  development  stage. 

2.4. 1.5  Message  Storage  and  Delivery 
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Since  many  of  the  recommended  DLSS  functions  require  the  capability  to 
process  on-line  requests  for  logistics  data,  it  is  important  to  design  the  LGN  to 
provide  the  capability  for  storing  responses  to  these  on-line  requests  until  they  can 
be  delivered  to  their  destinations.  The  LGN  should  also  be  able  to  interface  with  the 
existing  electronic  mail  systems  of  the  user  computer  facility  supported  by  the  LGN 
and  the  electronic  mail  system  of  the  DDN. 

The  ability  to  store  messages  is  required  for  the  following  reasons: 

•  It  may  not  be  possible  to  provide  an  immediate  response  to  an  on-line  query. 
For  example,  delays  are  likely  to  be  experienced  when  transactions 
generated  by  these  queries  require  data  from  more  than  one  remote  LGN- 
supported  site. 

•  Connections  between  the  LGN  and  its  user  computer  might  be  interrupted 
by  an  equipment  failure  or  the  loss  of  communications.  Thus,  it  is 
important  to  retain  the  ability  to  store  messages  until  service  has  been 
restored. 

•  The  communications  and  processing  equipment  of  the  logistics  system  will 
experience  occasional  peak  loading,  which  will  prevent  the  LGN  from 
servicing  requests  in  a  timely  manner.  With  storage  capability,  those 
messages  can  be  distributed  over  an  extended  time  period. 

•  Many  installations  within  the  logistics  community  experience  heavy 
volumes  of  message  traffic.  The  DAAS  sites  assemble  that  message  traffic 
into  batches  before  transmitting  it  to  its  intended  destination.  The  store- 
and-forward  capability  of  the  LGN  will  permit  batching  of  messages  that  do 
not  require  an  immediate  response. 

2.4.2  Operational  Functions 

This  category  of  functions  includes  ail  actions  directly  related  to  the  logistics 
process  —  servicing  queries;  establishing  priorities;  formatting  records;  and  routing. 
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passing,  and  editing  documents.  The  functions  included  in  this  category  are  summa¬ 
rized  below: 

•  Respond  to  inquiries  for  SOS  and  address  information. 

•  Respond  to  inquiries  related  to  requisition  tracking,  transportation  status, 
and  supply  availability  related  to  the  site  supported  by  an  LGN. 

•  Communicate  with  one  or  more  LGNs  to  obtain  data  required  to  satisfy 
local  requests. 

•  Track  throughout  the  LGN  network  to  respond  to  requests  listed  above;  e.g.. 
if  requisition  has  been  passed  to  another  SOS,  LGN  should  be  capable  of 
automatically  generating  a  second  request  to  the  new  SOS. 

•  Create  requisition  priority  using  the  Force  Activity  Designator  (FAD)  files 
and  urgency  of  need;  also  use  Required  Delivery  Date  (RDD)  for  creating 
transportation  priority. 

•  Accept  supplementary  data  files  (as  batch  input)  that  are  to  be  merged 
when  incomplete  records  are  received  from  a  host  to  create  complete  DLSS 
transaction. 

•  (Optional)  Manually  edit  and  merge  outgoing  records  to  add  supplementary 
information  not  supplied  by  the  user’s  primary  transaction  format. 

2.4.2. 1  Local  Queries 

The  DAAS  currently  processes  queries  related  to  data  stored  at  DAAS  sites.  It 
typically  processes  queries  on  SOS  for  specific  items,  cross  references  between  part 
numbers  (P/Ns)  and  NSNs,  and  site  addresses.  That  capability  would  be  incorpo¬ 
rated  into  the  LGNs  through  the  definition  of  query  transaction  formats  and  the  use 
of  local  data  bases  containing  the  information  required  to  satisfy  such  requests. 
Local  response  to  these  requests  eliminates  the  need  for  the  use  of  a  communications 
system  to  transmit  requests  from  the  customer  to  a  central  site. 

2. 4.2. 2  Queries  of  Remote  Data  Bases 

The  ability  to  process  on-line  queries  related  to  remotely  stored  information  is 
a  new  function  in  MODELS.  To  provide  this  function,  the  LGN  must  be  able  to 
identify  the  remote  site  at  which  the  required  data  are  stored.  It  must  also  be 
capable  of  performing  chained  searches  in  which  a  remote  site  can  •  • 

transaction  query  with  a  response  that  indicates  that  a  second  .emote  site  -a  . 
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interrogated.  When  this  type  of  response  is  received,  the  LGN  would  then  interro¬ 
gate  the  second  site. 

The  chained  search  permits  response  to  queries  related  to  requisition  status  in 
which  a  requisition  has  been  passed  to  an  alternative  SOS  or  the  supplies  have 
entered  the  transportation  system.  The  ability  to  provide  searches  of  remote  data 
bases  is  an  important  feature  of  the  LGN  architecture  in  that  it  minimizes  the 
requirement  for  the  maintenance  of  large  central  data  bases  that  duplicate  informa¬ 
tion  available  from  other  facilities.  Examples  of  applications  for  the  on-line  query  of 
remote  data  bases  include: 

•  Requisition  tracking,  in  which  the  LGN  processes  a  request  for  requisition 
status  by  interrogating  the  SOS  to  which  the  requisition  was  initially 
transmitted.  If  the  response  indicates  that  the  requisition  has  been  passed 
to  a  second  SOS,  the  LGN  automatically  interrogates  that  SOS.  In  its 
ultimate  configuration,  the  LGN  will  offer  the  capability  to  track  the 
requisition  through  the  transportation  system  by  transmitting  sequential 
transaction  queries  to  the  carriers  involved  in  the  shipment  of  the  requi¬ 
sitioned  items.  The  ability  to  track  requisitions  through  the  transportation 
system  will  probably  be  initially  implemented  within  the  Defense  Trans¬ 
portation  System  (DTS)  since  commercial  implementation  will  require  the 
cooperation  of  the  individual  carriers  for  totally  successful  operation. 

•  Requests  for  item  availability  through  the  transmission  of  a  standard 
transaction  query  to  the  appropriate  SOS.  With  the  ability  to  generate 
chained  queries,  the  LGN  can  identify  alternative  sources  of  supply  in  the 
event  that  the  primary  source  cannot  satisfy  the  anticipated  requirements 
of  the  user.  Such  queries  may  be  restricted  to  questions  on  the  availability 
of  specific  quantities  of  items  with  a  response  that  indicates  only  the 
availability  of  the  desired  quantity. 

•  Queries  for  catalog  information.  These  queries  could  be  transmitted  to  the 
site  responsible  for  the  management  of  the  item  using  a  standard  trans¬ 
action  format.  Queries  that  cannot  be  served  by  the  site  would  be  trans¬ 
mitted  to  the  Defense  Logistics  Service  Center  (DLSC).  Alternatively,  the 
LGN  can  be  programmed  to  automatically  send  all  requests  directly  to 
DLSC  in  a  format  compatible  with  DLSC  requirements. 

These  examples  of  the  servicing  of  on-line  queries  are  typical  of  the  manner  in 
which  the  LGN  would  operate.  The  capability  for  remotely  accessing  distributed 
data  bases  using  pairs  of  LGNs  communicating  in  a  common  DLSS  transaction 
format  results  in  a  DDBMS  architecture.  DDBMS  architectures  represent  an 


alternative  to  the  difficult  and  costly  maintenance  of  large  central  data  bases 
currently  used  as  a  source  of  information  for  remote  queries. 

The  LGN  architecture  minimizes  the  complexity  of  accessing  distributed  data 
bases  in  that  it  will  use  specific  DLSS  transaction  formats  for  queries.  The  definition 
of  a  common  format  reduces  the  complexity  of  the  query  translation  to  be  performed 
by  the  LGN  since  it  must  only  provide  translation  between  two  different  query 
languages,  the  local  computer  language  and  the  DLSS  language.  To  simplify  the 
DDBMS  requirements,  only  a  limited  number  of  queries  would  be  permitted. 

2.4.2. 3  Priorities 

The  existing  DLSS  require  that  requisition  priorities  be  calculated  in  terms  of 
the  originator’s  FAD  and  the  urgency  of  need.  The  FAD  defines  the  maximum 
requisition  priority  that  can  be  used  based  on  the  mission  of  the  originating  activity. 
In  MODELS,  the  FAD  would  set  the  maximum  requisition  priority  that  can  be 
assigned  by  an  organization.  The  LGN  architecture  includes  the  capability  for 
requisitions  to  include  specification  of  urgency  of  need  rather  than  priority.  The 
LGN  would  calculate  the  priority  using  the  requisitioning  organization’s  FAD 
(stored  in  the  LGN),  and  the  requisition-supplied  urgency  of  need. 

Transportation  priorities  would  be  calculated  similarly  by  using  the  RDD  in 
addition  to  the  FAD  and  the  urgency  of  need.  For  example,  a  requisition  may 
identify  both  the  supply  item  urgency  of  need  and  its  RDD  window  (e.g.,  21  through 
31  September).  That  window  might  be  several  days  after  the  requisition  date,  or  it 
might  be  several  weeks  later.  When  the  requisition  reaches  the  ICP  (or  depot),  the 
appropriate  supply  issue  processing  system  would  evaluate  both  the  LGN-assigned 
supply  issue  priority  and  the  RDD-window-calculated  transportation  priority.  If  the 
RDD  can  only  be  met  by  air  transportation,  an  air  priority  would  be  designated;  if  it 
can  be  met  by  scheduled  ground  transportation,  a  ground  transportation  priority 
would  automatically  be  designated.  {Note:  Either  or  both  ICP-  and  depot-processing 
systems  will  require  programming  changes  and  development  of  more  sophisticated 
issue-  and  shipment-processing  algorithms  to  accommodate  this  proposed  logistics 
system  operational  requirement.) 

The  RDD  should  also  be  considered  in  determining  issue  release.  If  the  RDD  is 
several  weeks  in  advance,  the  issue  should  be  suspended  as  a  tentative  one.  If  an 
equal  or  higher  priority  is  received  with  a  closer  RDD  and  both  can  be  filled  on  time 
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through  on-hand  or  backordered  stocks,  the  tentative  issue  should  be  lifted  and  the 
later  requisition  filled.  As  backordered  stock  is  received,  the  first  requisition  is 
again  placed  on  tentative  issue.  If  the  first  requisitioned  RDD  cannot  be  satisfied  if 
stock  is  issued  to  the  second  requisitioner,  the  first  requisition  should  maintain  first 
issue  priority. 

Thus,  the  combination  of  the  issue  priority  and  RDD  should  provide  a  more 
flexible  supply  system  and  should  minimize  the  air  challenge  program  requirement 
while  providing  satisfactory  fill  rates. 

2.4.2.4  Merging  Data 

The  LGN  architecture  can  accommodate  DLSS  changes  without  requiring 
simultaneous  implementation  of  those  changes  at  all  user  sites.  However,  in  some 
cases,  the  DLSS  changes  might  require  incorporation  of  information  not  included  in 
the  current  version  of  the  transaction  format.  For  example,  the  addition  of  new 
weapons  system  coding  requirements  that  cannot  be  provided  by  an  existing  user’s 
system  could  be  satisfied  through  entry  of  those  data  from  an  external  source. 

Thus,  the  LGN  must  have  the  ability  to  accept  supplementary  data  files  that 
can  be  merged  with  "partial”  files  received  from  a  user’s  system  that  has  not  yet  been 
programmed  to  satisfy  the  new  DLSS  requirement.  Supplementary  data  files  could 
be  entered  at  the  LGN  as  either  batch  transactions  or  interactive  additions,  and 
transmitted  from  the  local  computer  or  from  a  peripheral  device  such  as  a  terminal 
or  a  disk. 

This  capability  must  be  accompanied  by  the  appropriate  access  security 
restrictions. 

2.4.3  Document  Routing/Passing/Checking  Functions 

Routing,  passing,  and  checking  logistics  documents  are  the  primary  functions 
performed  by  the  DAAS  sites.  Those  functions  are  described  by  the  Military 
Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP)  and  DAAS  logistics 
standards.  The  LGN  would  perform  these  functions  in  essentially  the  same  manner 
as  they  are  currently  performed  by  DAAS. 

To  eliminate  duplicate  processing,  all  editing  would  be  performed  at  the 
originating  LGN.  The  originating  local  computer  would  be  automatically  informed 


of  any  rejected  documents.  Here  again,  communications  requirements  would  be 
reduced  by  eliminating  transmission  of  documents  that  are  subsequently  edited  and 
rejected  by  DAAS. 


The  following  modifications  would  be  required  to  the  manner  in  which  the 
DAAS  sites  currently  perform  the  routing/passing  and  editing  functions: 

•  The  LGNs  must  have  the  capability  to  accept  and  respond  to  mass  cancel¬ 
lation  requests  including  termination  of  foreign  military  sales  (FMS).  Mass 
cancellations  would  be  broadcast  from  the  Central  LGN  as  described  below. 

•  Wherever  possible,  all  part  identification  number  (PIN)  requisitions  would 
be  converted  to  NSN  requisitions  prior  to  their  transmission. 

•  Incoming  FMS  documents  would  be  automatically  transmitted  to  the 
International  Logistics  Control  Offices  (ILCO)  through  its  LGN.  Following 
ILCO  processing,  these  documents  would  be  routed  or  passed  to  the  LGN  at 
the  appropriate  logistics  destination.  Outgoing  FMS  documents  would  be 
automatically  routed  through  the  ILCO  before  they  are  transmitted  to  their 
foreign  destination. 

•  All  responses  to  status  requests  filed  by  the  requester  would  be  transmitted 
by  the  LGNs  to  their  appropriate  destinations.  The  LGN  would  continue  to 
perform  the  error  checking,  passing,  and  routing  of  these  documents  when 
appropriate. 

2.4.4  File  Maintenance  Functions 

To  provide  the  functions  previously  described,  the  LGNs  must  be  capable  of 
maintaining  the  data  bases  required  for  document  routing  and  responding  to  local 
queries  for  logistics  information.  It  will  also  be  necessary  to  maintain  data  bases 
that  serve  as  archives  for  the  transactions  processed  by  the  LGNs. 
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2.4.4. 1  LGN  On-Line  Data  Bases 

A  number  of  on-line  reference  files  have  been  identified  to  process  requests  for 
information  originating  from  the  local  users.  Those  files  include  the  general 
categories  of  addressing/communications  directories,  logistics  data  related  to  P/Ns, 
stock  numbers  and  SOS,  and  the  FAD  files  used  for  the  calculation  of  requisition 
priorities.  Files  identified  thus  far  that  are  larger  than  I  megabyte  (Mbyte)  and  that 
must  be  maintained  at  the  LGN  are  shown  in  Table  2-4. 
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TABLE  2-4 


MAJOR  LOGISTICS  GATEWAY  NODE  ON-LINE  FILE  SIZES 


File  name 

Average  file 
size 

(Megabytes) 

Update  volumes3 
(Kilobytes) 

DoD  Activity  Address  File  (DoDAAF) 

33 

52 

COMM  RI/DoDAAC  cross  reference 

2 

3 

SOS 

578  -  748 

558  -  722 

P/N  NSN  cross  reference 

260  -  600 

100  -  231 

FAD  by  DoDAAF 

2 

3 

Military  Assistance  Program  Address  File  (MAPAF) 

1 

2 

Zip  code 

3 

0 

Activity/Military  Routing  Identifier  (MILRI) 

5 

8 

Communications  activity  file  [Logistics 

Information  Data  Service  (LIDS)] 

2 

0 

Plain  Language  Address  Designator  (PLAD) 

5 

8 

Performance  activity  [Military  Supply  and 
Transportation  Evaluation  Procedures  (MILSTEP)- 
expanded] 

40 

0 

Miscellaneous  files  smaller  than  1  Mbyte 

2 

10 

Total  file  size 

933  -  1,443 

744  -  1,039 

1  File  updates  are  those  that  are  performed  remotely  from  the  Central  LGN  site 


The  files  shown  in  Table  2-4  must  be  updated  by  the  Central  LGN  at  periodic 
intervals.  The  local  LGNs  will  receive  updates,  perform  the  required  file 
maintenance,  and  initiate  back-up  activities.  The  Central  LGN  would  specify  the 
time  at  which  new  data  are  to  be  used  to  synchronize  operations  of  the  individual 
LGNs. 

The  need  for  frequent  file  updates  at  multiple  LGNs  appears  to  offset  many  of 
the  communications  benefits  derived  from  other  LGN  features;  however,  similar 
updates  are  currently  being  made  by  DAAS  to  more  than  200  logistics  facilities.  We 
anticipate  no  increase  in  communications  traffic  as  a  result  of  LGN  update 
requirements.  The  impact  of  the  communications  required  for  file  updates  can  be 
minimized  through  transmission  of  updates  during  off-peak  hours. 
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When  developing  this  LGN  architecture,  we  considered  the  possibility  of 
maintaining  these  large  files  at  a  central  location  that  would  be  interrogated  by  the 
individual  LGN  as  required.  However,  we  concluded  that  such  an  approach  would 
result  in  a  level  of  communications  traffic  equal  to  or  greater  than  the  communi¬ 
cations  traffic  resulting  from  the  file  updates.  In  addition,  the  use  of  central  files 
would  significantly  increase  system  vulnerability,  a  characteristic  that  is  avoided  by 
all  other  aspects  of  the  LGN  architecture. 

2.4. 4.2  Archived  Data  Bases 

The  DAAS  sites  maintain  archived  histories  of  all  communications  processed 
by  their  facilities  for  tracing  lost  transmissions,  retransmitting  interfund  billings, 
and  preparing  reports  of  system  performance  [Military  Supply  and  Transportation 
Evaluation  Procedures  (MILSTEP)]  and  communications  traffic  [Logistics  Informa¬ 
tion  Data  Service  (LIDS)].  The  LGNs  must  be  capable  of  capturing  the  data  required 
to  prepare  equivalent  reports. 

The  files  required  to  perform  these  functions  are  identified  in  Table  2-5.  The 
file  sizes  indicated  in  that  table  are  based  on  the  assumption  that  a  1-year  history  of 
all  interfund  billing  documents  will  be  stored  at  the  originating  LGN. 


TABLE  2-5 

MAJOR  ARCHIVED  FILE  SIZES 


File  name 

Average  size 
(Megabytes) 

Update  volumes^ 
(Kilobytes) 

Transmitted  document  archive  (30  days) 

53 

2 

Interfund  billing  archive  (1  year) 

317 

0 

Received  document  archive  (6  months) 

576 

0 

Total  archive  files 

_ 

946 

— 

2 

'File  updates  reference  the  updates  of  files  at  the  Central  LGN  site  from  locally  archived  data 


A  complete  6-month  history  of  all  received  data,  including  discrepancy  reports, 
would  be  retained  at  the  receiving  LGN  to  generate  required  standardized  perfor 
mance  and  communications  traffic  reports.  The  receiving  LGN  is  designated  as  the 
basic  data  source  for  report  generation  to  ensure  that  all  documents  included  in 


performance  reports  have  been  successfully  transmitted  through  the  communi¬ 
cations  system.  In  addition,  a  30-day  history  file  of  all  communications  would  be 
stored  at  the  originating  LGN  for  retransmission  of  lost  documents.  LGNs  would  not 
maintain  files  of  rejected  documents. 

2.4.5  Performance  Monitoring  Functions 

The  LGN  architecture  assumes  that  the  existing  DAAS  capability  for  the 
production  of  periodic  reports  related  to  system  performance  and  communications 
traffic  will  be  retained.  In  addition,  MODELS  requires  ad  hoc  reports  in  response  to 
the  needs  of  senior-level  personnel  within  the  DoD.  Both  of  these  capabilities  are 


included  as  LGN  functions. 


2.4.5. 1  Periodic  Reports 


Periodic  reports  similar  to  the  MILSTEP  and  LIDS  reports  currently  produced 
by  DAAS  would  be  produced  at  monthly  intervals.  Those  reports  would  be  prepared 
at  the  Central  LGN  site  using  data  retrieved  from  the  LGN  network  archived  data 
bases.  Retrieval  of  these  data  by  the  Central  LGN  could  either  be  performed  during 
off-peak  hours,  or  it  could  be  sent  on  disks  using  the  U.S.  Postal  Service  or  package 
express.  The  data  transfer  technique  used  should  be  determined  on  the  basis  of  an 
analysis  of  costs  and  requirements. 


The  printing  and  distribution  of  these  reports  would  be  performed  by  the  staff 
of  the  Central  LGN.  In  the  future,  these  capabilities  could  be  replaced  by  electronic 
distribution  of  information. 


The  LGN  concept  has  the  potential  for  improving  the  accuracy  of  the  MILSTEP 
reports  because  it  can  potentially  capture  all  logistics  data  traffic  (except  possibly 
intra-Service  traffic)  originating  at  its  site.  The  possibility  that  a  local  computer  will 
bypass  the  LGN  is  minimized  by  the  fact  that  communications  with  an  LGN  at 
another  site  requires  the  use  of  the  LGN  at  the  originating  site.  In  addition,  the 
features  and  flexibility  of  the  LGNs  should  encourage  their  increased  use. 


2.4. 5.2  Ad  Hoc  Reports 


The  LGN  system  design  will  include  the  ability  to  generate  ad  hoc  reports  in 
response  to  queries.  The  design  assumes  that  requests  for  ad  hoc  data  would  be 
routed  through  the  Central  LGN,  which  would  identify  the  sources  of  the  data 
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required  to  generate  the  requested  report.  Access  to  the  ad  hoc  reporting  capability 
must  be  restricted  to  a  limited  number  of  DoD  personnel  because  of  the  processing 
and  communications  load  that  can  be  created  by  large  numbers  of  requests  and 
because  of  the  potential  sensitivity  of  available  data. 

The  unpredictable  nature  of  ad  hoc  queries  requires  system  flexibility  that  is 
provided  through  access  to  the  distributed  data  bases  of  the  logistics  community.  To 
provide  this  capability,  the  system  must  be  able  to  access  the  data  bases  of  the  LGNs 
and,  to  a  limited  extent,  the  data  bases  of  the  local  user  computers  they  support. 
Since  the  LGN  data  bases  will  have  a  common  data  model  standard  and  will  use 
identical  DBMS  software,  access  to  the  data  they  maintain  can  be  performed  using 
common  query  and  response  formats. 

Access  to  user  data  bases  for  response  to  ad  hoc  queries  is  significantly  more 
difficult  because  of  the  potential  sensitivity  of  these  data  and  because  of  the  lack  of 
DBMS  standards.  For  these  reasons,  access  to  user  data  bases  will  be  restricted  to 
data  that  can  be  obtained  by  the  local  LGN  supporting  that  user  with  predefined 
queries  established  in  coordination  with  the  management  of  the  local  facility.  The 
use  of  standard  queries  minimizes  complexity  and  provides  the  user  facility  with  the 
required  data  security. 

Thus,  an  ad  hoc  report  would  be  processed  in  the  following  sequence: 

1.  Senior-level  DoD  personnel  would  initiate  a  query  from  a  terminal  con 
nected  to  the  Central  LGN  by  the  DDN.  The  query  would  be  transmitted 
using  either  electronic  mail  or  on-line  access. 

2.  The  Central  LGN  would  verify  the  authorization  of  the  individual  initiat¬ 
ing  the  request,  and  after  the  authorization  has  been  validated  would 
analyze  the  request  to  determine  which  remote  LGNs  must  be  interrogated 
to  acquire  the  required  information. 

3.  Queries  would  be  transmitted  from  the  Central  LGN  to  the  remote  LGNs 
using  a  common  DBMS  query  format.  The  remote  LGNs  would  verify  that 
the  Central  LGN  is  the  source  of  the  request. 

4.  If  the  required  information  is  available  from  the  data  base  of  the  LGN,  it 
would  respond  to  the  request.  If  the  user  system  must  be  accessed  to 
acquire  the  information,  the  LGN  would  verify  the  availability  of  the 
information  and  format  a  query  for  the  user’s  data  base.  The  retrieved 
information  would  then  be  returned  to  the  central  site.  If  the  LGN  cannot 
access  the  required  user  information  because  the  user  is  not  operational  or 


the  data  are  not  available,  it  would  transmit  a  code  to  the  central  site 
indicating  that  the  information  cannot  be  provided. 


5.  Following  receipt  of  the  required  information  at  the  central  site,  a  report 
would  be  formatted  and  returned  to  the  requesting  terminal. 

2.4.6  Mobilization  and  Continuity  of  Operations  Plans 

Mobilization  readiness  requirements  will  be  considered  when  determining 
hardware  requirements,  designing  software,  and  developing  mobilization  contin¬ 
gency  plans.  A  mobilization  and  surge  sensitivity  analysis  will  be  performed  during 
system  specification  to  determine  the  cost  and  feasibility  of  continued  processing  of 
various  critical  and  noncritical  functions  during  mobilization.  The  system  should  be 
capable  of  handling  substantial  processing  increases  without  imposing  significant 
impacts  on  ongoing  operations.  Priority  handling  functions  will  be  specified,  and  a 
determination  will  be  made  as  to  which  functions  are  to  be  dropped  in  emergencies. 


Since  logistics  operations  are  required  24  hours  a  day,  7  days  a  week,  individ¬ 
ual  sites  must  have  back-up  capabilities  and  must  be  capable  of  providing  back-up 
for  each  other.  Contingency  planning  should  include  back-up  procedures,  emergency 
measures,  methods  for  handling  peak  workloads,  recovery  procedures,  procedures  for 
returning  to  normal  processing,  and  other  procedures  to  assure  rapid  contingency 
processing. 

The  LGN  should  provide  the  priority  scheme  and  processing  capacity  sufficient 
to  sustain  critical  functions  during  mobilization  and  wartime  and  as  soon  as  possible 
after  LGN  operations  have  been  disrupted  by  natural  disasters  or  other  contin¬ 
gencies.  Procedures  should  be  specified  to  ensure  that  mobilization  and  wartime  are 
considered  in  LGN  planning  and  design  specifications.  These  procedures  should 
include: 

•  Plans  to  minimize  data  losses  during  and  immediately  after  catastrophic 
events 

•  Plans  to  provide  alternative  support  for  LGN  subscribers  during  periods, 
brief  or  protracted,  when  they  are  denied  normal  support  because  of 
emergencies 

•  Plans  to  reduce  to  a  minimum  the  time  between  automatic  data  processing 
(ADP)  failure  because  of  a  catastrophe  and  restoration  of  acceptable  support 
levels. 
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A  Continuity  of  Operations  Plan  (COOP)  should  be  developed  for  each  site 
during  implementation.  A  current  copy  of  each  COOP  should  be  maintained  in  a 
remote  storage  area  (off-site).  The  COOP  should  include  an  evaluation  of  the  vulner¬ 
ability  of  sites,  systems,  and  functions  to  disaster,  combat,  and  sabotage.  It  should 
identify  differences  in  site  operations,  organization,  staffing,  and  support  require¬ 
ments  during  peacetime,  mobilization,  and  wartime.  As  part  of  the  COOP, 
functional  information  requirements  should  be  reviewed  to  determine  wartime- 
essential  data,  information  flows,  workloads,  data  and  function  priorities,  and 
special  requirements.  A  primary  and  alternate  contingency  manager  should  be 
identified  to  coordinate  back-up  and  recovery.  The  COOP  should  describe  proce¬ 
dures  for  retaining  and  copying  master  files  and  for  reconstructing  damaged  or 
destroyed  files.  The  COOP  also  describes  procedures  for  assuring  that  at  least  one 
current  copy  of  all  data  critical  to  sustained  operations,  including  applications 
programs,  control  files,  and  system  software,  is  kept  at  a  location  other  than  the 
main  storage  site.  The  COOP  also  contains  provisions  for  the  following: 

•  Back-up  for  all  telecommunications  requirements 

•  Capability  to  perform  critical  functions  manually  in  emergency  situations 

•  Personnel  training  and  readiness 

•  Identification  for  intersite  and  intrasite  resource  sharing 

•  Provision  for  alternative  administrative  and  system  management  proce¬ 
dures 

•  Reconstitution  procedures  and  support  requirements 

•  Computer  disaster  recovery,  test  and  evaluation  plan. 

2.5  CENTRAL  LOGISTICS  GATEWAY  NODE 

The  proposed  MODELS  requires  a  Central  LGN.  The  LGN  architecture 
assumes  that  the  Central  LGN  will  be  operated  at  the  existing  DAAS  site  in  Dayton, 
Ohio  and  will  probably  use  its  planned  data  processing  equipment.  This  LGN  would 
perform  all  functions  required  for  central  control  of  the  local  LGNs,  such  as  data  base 
updates  and  software  configuration  management.  It  would  also  be  used  as  the  entry 


point  to  the  system  for  ad  hoc  queries  and  for  preparation  of  periodic  reports.  The 
specific  functions  performed  by  the  Central  LGN  are  as  follows: 

•  Transmit  software  updates  to  remote  LGNs. 

•  Receive  inquiries,  assemble  data  (from  other  LGNs),  perform  analysis,  and 
prepare  all  ad  hoc  reports. 

•  Assemble  data,  prepare,  print,  microfilm,  and  distribute  all  periodic  reports. 

•  Broadcast  MINIMIZE  condition  to  all  local  LGNs. 

•  Receive  and  broadcast  all  mass  cancellation  requests. 

•  Receive  and  distribute  (to  all  LGNs)  all  data  base  updates  [DoD  Activity 
Address  File  (DoDAAF),  SOS  files,  etc.]. 

•  Maintain  all  archival  data  to  be  stored  more  than  1  year. 

•  Provide  off-site  back-up  for  all  critical  local  LGN  data. 

•  Provide  all  media  conversion  activities:  electronic  data  to  hard  copy 
(including  mail),  punch  cards  to  electronic  data,  electronic  data  to  micro¬ 
fiche,  etc.  A  back-up  for  the  media  conversion  capability  must  be  provided 
at  a  second  LGN. 

The  Central  LGN  performs  only  functions  requiring  central  support  or  func 
tions  that,  if  performed  centrally,  will  reduce  the  cost  and  complexity  of  the 
individual  LGN  configurations.  In  all  cases,  the  Central  LGN  functions  are  those 
that  can  be  implemented  at  a  single  site  without  affecting  the  overall  vulnerability 
of  the  system.  Further  reductions  in  vulnerability  can  be  achieved  by  designating 
one  of  the  other  LGNs  as  a  back-up  for  the  Central  LGN.  The  functions  for  which 
back-up  is  required  are  identified  in  the  following  discussion. 

2.5.1  Configuration  Management  Operations 

The  successful  operation  of  the  LGN  architecture  requires  strict  management 
and  standardization  of  the  hardware  and  software  at  each  local  site.  The  system 
architecture  must  be  designed  to  permit  updating  LGN  programs  and  data  from  a 
central  site.  Transmission  of  all  updates  would  be  accompanied  by  the  time  and  date 
the  update  is  to  be  implemented  in  order  to  coordinate  the  overall  system  operation. 
This  is  critical.  Although  immediate  updating  of  software  and  data  bases  is  not 
critical  to  the  logistics  system  operation,  the  absence  of  this  capability  for  more  than 
2  weeks  will  seriously  reduce  the  effectiveness  of  logistics  operations.  Thus,  the 


LGN  architecture  must  incorporate  the  capability  to  provide  updates  from  alterna 
tive  LGN  sites. 
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Data  base  updates  would  be  performed  to  all  on-line  files  including  the  SOS 
file,  the  DoDAAF,  the  Military  Assistance  Program  Address  File  (MAPAF),  DoD 
Routing  Identifier  (DoD  RI)  codes  and  distribution  codes,  and  the  activity  address 
file  including  the  COMM  RI  and  DoD  Activity  Address  Directory  (DoDAAD)  cross 
references.  Data  base  updates  will  also  be  required  for  the  operational  tables  that 
define  the  reformatting  of  local  user-to-DLSS  data  formats,  restrictions  to  access  of 
the  user  data  base,  and  definition  of  local  user  data  base  contents. 

Although  not  directly  related  to  configuration  management,  the  Central  LGN 
should  also  be  considered  a  potential  location  for  off-site  storage  of  data  bases.  This 
site  will  automatically  store  all  data  base  updates  transmitted  to  the  local  LGNs, 
eliminating  the  need  for  redundant  back-up  storage  at  the  local  sites.  Additional 
back-up  can  be  provided  automatically  through  the  storage  of  data  transmitted  from 
the  local  LGNs  to  the  central  site  for  the  development  of  the  periodic  reports.  These 
two  data  bases  include  the  majority  of  data  maintained  at  the  LGN  sites.  Thus,  it  is 
unlikely  that  extensive  back-up  storage  will  be  required  at  the  local  sites. 

Software  updates  from  the  Central  LGN  will  be  required  for  program  mainte¬ 
nance  and  for  responding  to  changes  in  the  DLSS  and  user  configurations  that 
cannot  be  accommodated  through  data  base  modifications. 

2.5.2  Reporting  and  Query  Processing 

Periodic  reports  will  be  processed  using  a  central  data  base  assembled  from  the 
data  transmitted  to  the  Central  LGN  from  local  LGNs.  These  reports  would  be 
produced  using  standard  report  formats. 

Ad  hoc  queries  would  be  processed  by  the  Central  LGN  by  transmitting  data 
requests  to  the  individual  LGNs  defining  the  information  that  is  required.  The  data 
received  from  the  remote  LGNs  would  be  assembled  in  a  temporary  data  base  and 
processed  using  a  general-purpose  DBMS.  The  query  formats  should  be  defined  in  a 
manner  that  is  consistent  with  the  requirements  of  the  DBMS  to  minimize  the 
requirement  for  additional  translation. 

The  response  to  ad  hoc  queries  related  to  supply  and  shipment  status  in  support 
of  major  operations  can  be  extremely  critical.  For  this  reason,  alternate  LGNs 


(including  those  installed  at  foreign  theaters)  must  offer  the  capability  of  processing 
ad  hoc  queries  as  back-up  to  the  Central  LGN.  However,  one  of  the  benefits  of  using 
the  Central  LGN  for  the  entry  of  ad  hoc  queries  is  the  availability  of  a  knowledge¬ 
able  staff  to  assist  the  user  in  formulating  queries.  That  capability  will  not 
necessarily  be  available  at  all  remote  LGN  sites. 


The  Central  LGN  is  expected  to  serve  as  the  primary  node  for  supporting  Joint 
requirements  for  logistics  information.  As  JOPES  and  related  projects  evolve  and 
Joint  requirements  are  more  clearly  defined,  they  will  be  incorporated. 


2.5.3  Broadcast  Operational  Changes 


The  Central  LGN  would  initiate  all  changes  to  system-wide  operation.  These 
changes  would  include  initiation  of  the  MINIMIZE  mode  of  operation  and  mass 
cancellation  requests.  These  operational  changes  must  be  initiated  only  by  person¬ 
nel  with  authorized  access  codes.  While  this  capability  could  be  provided  at  all  LGN 
sites,  its  use  should  be  restricted  to  a  single  site  with  back-up  from  a  second  LGN  site 
to  minimize  the  chance  of  unauthorized  use  of  this  feature. 


2.5.4  International  Logistics  Communications  System  (ILCS)  Interface 


For  ILCS  users,  the  Defense  Automatic  Addressing  System  Office  (DAASO) 
has  developed  message-formatting  and  routing  schemes  that  are  similar  to 
AUTODIN  formats.  All  ILCS  logistics  traffic  is  transmitted  from  the  ILCS 
subscriber  to  the  DAAS  Dayton,  Ohio  site,  where  it  is  routed  first  to  the  ILCO  and 
then  to  the  appropriate  logistics  facility.  This  mode  of  operation  would  be  modified 
by  the  LGN  architecture;  all  ILCS  users  would  have  to  communicate  directly  with 
the  ILCO’s  LGN.  When  ILCO  processing  is  complete,  the  transaction  would  be 
routed  to  the  appropriate  logistics  facility. 


2.5.5  Media  Conversion 


DAAS  currently  offers  the  capability  to  communicate  between  sites  using  a 
number  of  alternative  media  and  formats.  While  the  majority  of  transactions  use 
electronic  data  transmission  in  computer-readable  form,  DAAS  also  receives 
narrative  messages  from  either  teletype  or  dial-up  communications  services,  and 
hard  copy  messages  from  mail  or  courier.  These  messages  are  currently  entered  into 
the  logistics  system  manually  as  batch  transactions.  This  service  would  be  retained 
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at  the  Central  LGN  site  with  the  exception  that  data  would  be  entered  using  on-line 
terminals  or  other  methods  of  source  data  automation. 


A  second  LGN  site  should  provide  the  back-up  media  conversion  capability. 
The  Central  LGN  would  also  perform  the  equivalent  output  conversion  (also 
performed  by  DAAS)  from  electronic  data  to  hard  copy  or  to  narrative  teletype 
messages. 

The  Central  LGN  should  perform  any  media  conversions  required  during 
MINIMIZE  conditions.  Data  can  be  mailed  or  sent  by  courier  to  the  central  site  on 
either  disks  or  tape  where  it  would  be  converted  to  hard  copy  output  and  mailed  to 
the  appropriate  destination. 

The  Central  LGN  will  also  produce  all  printed  output  and  provide  all  micro¬ 
filming  services  associated  with  the  distribution  of  reports.  Those  services  would 
include  the  conversion  from  tape  to  microfilm  and  the  distribution  of  the  output  to 
the  appropriate  recipients. 

2.6  MANAGEMENT  ISSUES 

The  LGN  architecture  requires  a  centrally  managed  standard  configuration. 
The  standardization  requires  the  use  of  compatible,  stand-alone  processors  capable 
of  receiving  remote  updates  from  a  central  source.  These  constraints  on  system 
design  and  maintenance  require  the  availability  of  a  centralized  staff  responsible  for 
the  acquisition  and  maintenance  of  the  LGN  hardware,  development  of  software, 
and  maintenance  of  data  bases. 

The  central  staff  responsibilities  should  include: 

•  All  software  development,  maintenance,  and  enhancements. 

•  Receiving,  reviewing,  and  transmitting  all  data  base  updates  to  the  remote 
LGNs. 

•  Coordinating  the  requirements  of  the  Services  for  LGN  services  including 
identification  and  support  for  Service-unique  processing,  coordination  of 
Service  user  computer  configuration  modifications,  interfaces  with  DoD 
data  communications  services,  and  coordination  with  all  nearby  facilities 
served  by  the  LGNs. 

•  Continued  support  to  ILCS  subscribers  including  management  of  the  ILCS 
equipment,  training,  media  conversion,  etc. 
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•  Management  of  personnel  required  to  provide  operations  and  maintenance 
support  of  the  LGNs  at  the  remote  site,  including  monitoring  of  personnel 
activities,  training,  and  hiring. 

•  Management  of  all  LGN  equipment  procurement  activities,  including 
system  design,  specification,  contractor  performance  monitoring,  and  accep¬ 
tance  testing 

•  Maintenance  of  all  LGN  hardware.  Maintenance  activities  would  be  the 
responsibility  of  on-site  personnel  with  diagnostic  support  provided  from 
the  central  site.  Diagnostic  support  would  be  provided  through  remote 
access  and  remote  control  of  local  LGN  processors. 

Since  many  of  these  services  are  currently  provided  by  the  existing  DAASO 
staff,  it  is  likely  that  DAASO  would  retain  them  and  would  adapt  them  to  the 
requirements  of  the  LGN  architecture. 

Since  the  expanded  capabilities  of  the  LGNs  will  have  a  greater  impact  on  the 
operation  of  the  entire  defense  logistics  system  than  on  the  existing  DAAS  sites, 
consideration  should  be  given  to  establishing  a  Joint  management  team  (such  as  the 
DLSS  focal  point  committees)  to  establish  the  requirements  for  LGN  operations. 
That  team  would  identify  and  define  Service  requirements,  define  surge  capabilities, 
and  identify  the  need  for  new  LGN  sites. 

2.7  COST  ESTIMATES 

2.7.1  Approach 

The  development  of  a  reliable  cost  estimate  requires  preparation  of  a  detailed 
system  functional  description  that  can  be  used  to  estimate  the  lines  of  software  code 
and  computer  resources  required  to  support  LGN  operations.  The  surge  capability 
and  security  requirements  must  also  be  defined.  This  document  does  not  provide 
sufficient  detail  to  develop  this  type  of  estimate.  However,  a  preliminary  estimate  of 
system  costs  to  determine  whether  the  system  is  affordable  and  to  compare  the  LGN 
operating  costs  with  those  of  the  existing  DAASO  system  follows. 

Estimates  were  developed  by  comparing  the  peacetime  volume  of  document 
traffic  to  be  processed  by  the  LGNs  with  transaction  processing  functions  of  similar 
commercial  and  military  systems.  From  those  comparisons,  we  developed  prelim 
inary  estimates  of  the  hardware  acquisition  costs. 
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Software  implementation  costs  are  based  on  the  assumption  that  the  number  of 
lines  of  software  code  used  to  provide  the  LGN  processing  functions  will  be 
equivalent  to  those  in  the  current  DAAS  computer  configuration.  Available 
conversion  factors  that  relate  the  number  of  lines  of  code  to  manpower  requirements 
are  used  to  estimate  the  software  costs.  Recurring  operations  and  maintenance  costs 
are  estimated  using  similar  procedures  and  factors. 


The  DAAS  modernization  plans  [DAAS  ADPE  Replacement  Program  (DARP)] 
provide  additional  uncertainty  in  the  development  of  the  cost  estimates.  The  DARP 
has  been  reviewed  and  appears  to  offer  many  of  the  features  required  by  the  Central 
LGN.  It  also  includes  the  development  of  some  software  that  may  be  transferable  to 
the  remote  LGNs.  Thus,  software  development  cost  savings  that  are  not  reflected  in 
the  following  cost  estimate  may  be  possible. 


When  reviewing  this  cost  estimate,  it  is  important  to  recognize  that  many  of 
the  functions  and  locations  served  exceed  the  capabilities  and  services  of  the  existing 
DAAS  configuration.  The  following  estimates  are  presented  in  terms  of  1986  costs. 
The  future  effects  of  inflation  and  the  possibility  of  future  decreases  in  data  process¬ 
ing  equipment  costs  have  not  been  considered. 


2.7.2  Hardware  Costs 


The  hardware  cost  estimate  is  based  on  a  local  LGN  operational  profile 
developed  from  the  following  sources: 


•  The  LIDS  data  base  was  used  to  develop  estimates  of  communications  traffic 
for  the  90  sites  processing  the  greatest  amount  of  logistics  communications 
traffic.  These  sites  accounted  for  approximately  85  percent  of  the  traffic 
processed  by  DAAS.  These  data  represent  the  existing  traffic  processed  by 
DAAS;  they  do  not  include  the  future  traffic  resulting  from  the  enhanced 
capabilities  of  the  LGNs. 


•  Additional  assumptions  were  made  related  to  traffic  growth  using  the  data 
from  the  MODELS  Phase  2  report.  That  report  projected  an  increase  of 
292  percent  over  that  which  is  currently  experienced  by  DAAS.  These 
factors  were  used  for  the  projection  of  traffic  loading  at  the  individual  sites. 


•  File  sizes  and  file  update  traffic  were  developed  from  the  data  presented  in 
the  Defense  Automatic  Addressing  System  Office  Baseline  Functional  Speci¬ 
fication  ( DAASO-BFS)  developed  for  DLA  by  Advanced  Technology,  Inc.,  in 
August  1984. 


•  Sizes  of  programs  and  supporting  data  bases  were  also  derived  from  data 
presented  in  the  DAASO-BFS. 

Data  from  those  sources  served  as  the  basis  for  the  processor  loading  projec- 
tions  presented  in  Table  2-6.  The  data  presented  in  the  column  titled  "Level” 
represent  the  average  data  anticipated  at  the  LGN  sites.  The  "Maximum  level” 
column  represents  the  worst  case  conditions  anticipated  at  the  busiest  site.  The 
variation  in  major  on-line  file  storage  between  these  two  columns  reflects  the 
anticipated  expansion  of  the  SOS  file  to  include  the  NSN,  unit  of  issue,  and  price 
data.  The  values  used  in  the  "Maximum  level”  column  were  used  to  develop  the  cost 
estimates  presented. 

TABLE  2-6 

LOCAL  SITE  LOGISTICS  GATEWAY  NODE  PROJECTED  PROCESSOR  LOADING 


Activity 

Level 

Maximum  level 

Operational  incoming  logistics  traffic 

1 .0  Mbyte/hour 

19  0  Mbytes/hour 

Operational  outgoing  logistics  traffic 

2.0  Mbytes/hour 

7  0  Mbytes/hour 

Total  operational  logistics  traffic 

3.0  Mbytes/hour 

19  0  Mbytes/hour 

Average  length  of  one  transaction 

72  0  bytes 

180  0  bytes 

Incoming  file  update  traffic 

74.0  Kbytes/hour 

104  0  Kbytes/hour 

Outgoing  file  update  traffic 

0.2  Kbytes/hour 

1  2  Kbytes/hour 

On-line  storage  for  maior  files 

933  0  Mbytes 

1,650.0  Mbytes 

Storage 

Back-up  (off-line  storage)  for  major  files 

933  0  Mbytes 

1,650  0  Mbytes 

Off-line  storage  for  archive  files 

946  0  Mbytes 

4,730.0  Mbytes 

On-line  storage  for  programs  and 
supporting  data  bases 

4  0  Mbytes 

4  0  Mbytes 

Back-up  (off-line  storage)  for  programs 
and  supporting  data  bases 

4  0  Mbytes 

4  0  Mbytes 

Total  on-line  storage 

937  0  Mbytes 

1 ,654  0  Mbytes 

Total  off-line  storage 

1 ,883  0  Mbytes 

6,384  0  Mbytes 

Note:  kbytes  =  kilobytes 


These  data  were  used  to  develop  the  following  processing  configuration: 

•  The  computer  processing  configuration  will  include  identical  dual  proces¬ 
sors  with  full  redundancy  and  back-up  capabilities.  The  processor  charac¬ 
teristics  include  a  32-bit  word  length,  memory  expansion  up  to  8  megabytes 
per  processor,  and  a  memory  access  time  of  400  nanoseconds.  The 
configuration  consists  of  a  fault-tolerant  architecture  including  redundant 
power  supplies  and  interprocessor  communications  facilities.  Each  of  the 
processors  is  equipped  with  4  megabytes  of  memory  and  15  input/output 
(I/O)  ports. 

•  Formatted  disk  storage  of  3.3  gigabytes  (Gbytes)  has  been  included  in  the 
configuration  for  storage  of  on-line  disk  files.  The  disk  storage  has  been 
sized  to  accommodate  redundant  storage  of  the  on-line  data  base  at  its 
maximum  level. 

•  Optical-disk  storage  of  1.0  gigabyte  has  been  provided  for  on-line  storage  of 
the  received  document  archive.  That  storage  would  be  used  for  response  to 
ad  hoc  queries  related  to  documents  received  by  the  LGN. 

•  A  magnetic  tape  drive  has  been  provided  for  recording  archived  data 
including  back-up  data  for  the  received  document  archive.  The  tape  drive 
would  also  be  used  to  generate  off-site  magnetic  tape  back-ups  of  on-line 
data  bases  and  software. 

•  The  estimate  includes  a  medium  speed  (300-lines  per  minute)  line  printer 
for  producing  local  listings  of  data  bases  and  operating  logs. 

The  estimated  cost  of  this  local  LGN  configuration  using  1986  pricing  data  is 
$230,000.  That  cost  is  based  on  the  General  Services  Administration  (GSA)  schedule 
prices  for  unit  quantities  of  this  equipment.  An  additional  $30,000  must  be  added  to 
the  total  cost  of  the  LGN  installation  to  account  for  minor  facility  modifications 
required  to  house  the  LGN.  Thus,  the  cost  of  the  LGN  hardware  implementation  for 
all  major  logistics  sites  is  estimated  to  be  $26  million. 

2.7.3  Software  Costs 

Software  costs  were  developed  using  existing  DAAS  statistics  summarized  in 
Table  2-7.  That  table  indicates  that  the  DAAS  software  has  been  programmed  using 
the  Common  Business  Oriented  Language  (COBOL)  compiler  language  and  the 
COMPASS  assembly  language.  The  total  lines  of  code  have  been  converted  to 
equivalent  machine  instructions  using  a  factor  of  six  machine  instructions  per  line  of 


compiler  code.  The  COMPASS  code  generates  one  machine  instruction  for  each  line 
of  source  code. 

TABLE  2-7 

SOFTWARE  DEVELOPMENT  REQUIREMENTS 


Item 

Computer 
source  code 

Assembly 
language 
source  code 

Existing  DAAS  system  statistics: 

Total  lines  of  code 

180,000 

183,000 

Equivalent  machine  instructions 

1,080,000 

183,000 

Number  of  programs 

400 

322 

Average  lines  of  code  per  program 
Program  development  estimates: 

450 

568 

Estimated  lines  of  code  to  be 
converted 

64,000 

— 

Estimated  lines  of  code  to  be 
replaced  by  general  purpose  DBMS 

25,000 

30,000 

Estimated  lines  of  new  code 

95,000 

150,000 

Estimated  labor  hours  required 

190,500 

37,500 

Total  development  labor 

228,000  hours 

1 10  man-years 

Total  maintenance  labor 

22  man-years/year 

The  number  of  lines  of  code  to  be  converted  was  developed  assuming  that  the 
DAAS  routing,  passing,  and  error-checking  functions  would  be  performed  by  the 
local  LGNs  in  the  same  way  they  are  currently  performed.  As  a  result,  these  pro¬ 
grams  may  be  convertible  without  significant  reprogramming.  It  was  assumed  that 
new  code  would  have  to  be  developed  for  all  other  functions.  However,  in  some  cases, 
the  new  code  would  be  replaced  by  the  use  of  general-purpose  DBMS  software  since 
many  of  the  DAAS  programs  involve  file  maintenance,  access,  and  updating. 

The  factors  used  to  convert  these  lines  of  code  to  programming  labor  are  as 
follows.  New  software  are  programmed  at  the  rate  of  four  object  instructions  per 
hour.  Existing  programs  converted  at  the  rate  of  10  object  instructions  per  hour.  All 
estimates  include  definition,  analysis,  design,  coding,  testing,  documentation,  and 


management  of  the  software  development.  Annual  software  maintenance  and 
support  is  assumed  to  equal  20  percent  of  the  development  labor.  These  estimates 
are  from  Quantitative  Management:  Software  Cost  Estimating,  COMPSAC  77,  IEEE 
Computer  Society,  Piscataway,  New  Jersey.  That  reference  also  served  as  a  source 
for  estimating  the  software  maintenance  requirements  discussed  in  the  following 
section. 

On  the  basis  of  this  analysis,  we  have  concluded  that  110  man-years  will  be 
required  for  the  development  of  the  software  required  by  the  LGN  architecture. 
Assuming  that  1  man-year  is  equivalent  to  $100,000  in  annual  contract  costs 
(including  direct  labor,  overhead,  other  direct  costs,  and  profit),  the  total  software 
development  cost  will  be  approximately  $11  million.  These  costs  do  not  include  the 
cost  of  Government  administration  of  contractor  supplied  services,  since  at  this  time 
the  organization  responsible  for  the  software  development  has  not  been  identified. 
This  software  could  be  developed,  tested,  and  implemented  by  DAASO  staff. 

2.7.4  Operations  and  Maintenance  Costs 

The  costs  associated  with  the  ongoing  operation  of  the  LGN  system  include 
equipment  operations,  hardware  maintenance,  and  software  maintenance  and 
updating.  These  costs  have  also  been  developed  using  experience  of  other  facilities 
and  available  conversion  factors. 

The  following  operations  and  maintenance  costs  can  be  anticipated: 

•  Operations  costs  assume  that  one  system  operator  will  be  required  for  each 
shift.  One  of  the  operators  will  act  as  a  supervisor  for  the  operations  person¬ 
nel.  Thus,  a  total  of  four  operators  will  be  required  at  each  LGN  site.  Fewer 
operators  may  be  necessary  if  personnel  from  the  staff  of  the  user  facility 
can  be  made  available  to  monitor  the  LGN  operation. 

•  Annual  equipment  maintenance  has  been  estimated  from  industry 
averages,  which  equal  approximately  10  percent  of  the  purchase  price. 
Therefore,  the  total  system-wide  maintenance  cost  will  be  $2.6  million  per 
year. 

•  Annual  software  maintenance  labor  is  anticipated  to  equal  20  percent  of  the 
initial  development  effort.  Therefore,  a  total  software  maintenance  staff  of 
22  programmers  and  management  personnel  will  be  required. 


2.7.5  Total  Local  Logistics  Gateway  Nodes  Implementation  and  Operations* 
Maintenance  Costs 

The  total  system  implementation  costs  (for  hardware  and  software)  are  sum¬ 
marized  in  Table  2-8. 


TABLE  2-8 

TOTAL  SYSTEM  IMPLEMENTATION  COSTS 


The  required  system  operations  and  maintenance  resources  have  been  divided 
into  categories  of  Government  personnel  and  contract  maintenance  support.  These 
resources  include: 

•  Programming  and  management  support  —  22  individuals 

•  Site  operations  support  —  400  individuals 

•  Total  staff  support  requirements  —  422  individuals 

•  Total  contract  maintenance  support  —  $2.6  million  per  year. 

2.7.6  Local  Logistics  Gateway  Nodes  Life-Cycle  Costs 

This  cost  estimate  has  been  used  to  develop  an  approximate  system  life-cycle 
cost.  These  estimates  provide  the  data  required  to  assess  the  feasibility  of  the 
continuing  development  of  the  LGN  architecture.  A  more  precise  definition  of  these 
costs  must  be  prepared  as  the  architecture  is  further  defined. 

The  life-cycle  cost  estimate  has  been  developed  using  the  following  assump 

tions: 

•  System  life  will  be  10  years. 

•  Inflation  has  not  been  included  in  the  estimate. 


•  The  system  will  be  implemented  over  a  5-year  period  using  the  following 
schedule: 

>  First  year:  one-half  software  development. 

>  Second  year:  one-half  software  development  and  implementation  of  first 
five  sites. 

>  Third  year:  25  sites  implemented. 

>  Fourth  year:  30  additional  sites  implemented, 
t  Fifth  year:  40  additional  sites  implemented. 

•  The  maintenance  programming  staff  will  be  established  during  the  second 
year  of  system  operation. 

•  The  life-cycle  costs  include  system  acquisition,  programming  staff  salaries, 
operations  staff  salaries,  and  maintenance  costs.  The  costs  of  floor  space 
and  environmental  controls  for  the  system  are  not  included. 

•  Salaries  include  base  salaries  increased  by  a  factor  of  1.26  for  fringe 
benefits.  Operations  staff  salaries  have  been  increased  by  an  additional 
8  percent  reflecting  cost  of  overtime  and  weekend  premium  rates. 

•  The  average  annual  base  salaries  used  include: 
t  Programmer  —  $35,000. 

t  Operators  —  $25,000. 

These  average  salaries  include  team  leader’s  salaries. 

2.7.7  Central  Logistics  Gateway  Node  Implementation  and  Operations- 
Maintenance  Costs 

The  cost  estimates  presented  in  this  section  assume  that  the  equipment  and 
software  being  acquired  for  the  DARP  will  be  compatible  with  the  requirements  of 
the  Central  LGN.  For  that  reason,  the  cost  of  the  Central  LGN  implementation  has 
been  assumed  equal  to  the  cost  of  the  other  LGN  installations,  to  provide  for  the 
acquisition  of  a  computer  configuration  to  be  used  as  a  software  development 
testbed.  The  development  costs  of  the  Central  LGN  software  are  included  in  the 
total  software  development  costs  of  the  preceding  section. 


The  recurring  Central  LGN  operations  and  maintenance  costs  are  equivalent 
to  the  operations  and  maintenance  costs  of  the  DARP  configuration  at  the  Dayton, 
Ohio  site.  Current  DARP  staffing  plans  for  that  site  include: 

•  A  staff  of  32  to  provide  technical  applications  support  for  applications, 
telecommunications,  and  operating  system  software. 

•  A  staff  of  10  to  provide  reports  and  support  to  other  organizations;  this  staff 
will  also  provide  support  for  the  ad  hoc  inquiry  capability  of  the  Central 
LGN. 

•  A  staff  of  60  for  system  operations;  some  systems  operations  personnel  will 
be  reassigned  to  the  other  two  activities. 

•  An  additional  staff  of  48  management  and  clerical  personnel. 

It  is  anticipated  that  an  equivalent  staff  size  will  be  required  to  support  the 
Central  LGN  operation  in  addition  to  the  management  of  the  LGN  activities  at  the 
field  locations. 

Using  these  assumptions,  life-cycle  costs  have  been  developed  and  are  shown  in 
Tables  2-9  through  2-11. 

TABLE  2-9 

ACQUISITION  COSTS 


Year 

Number  of  sites 
installed 
(cumulative) 

Software 

($000) 

Hardware 

($000) 

Total 

acquisition  cost 
($000) 

1 

0 

5,500 

— 

5,500 

2 

5 

5,500 

1,300 

6,800 

3 

30 

0 

6,500 

6,500 

4 

60 

0 

7,800 

7,800 

5 

100 

0 

10,400 

10,400 

6-10 

100 

0 

0 

0 

Total 

1 1,000 

26,000 

37,000 

m 
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TABLE  2-10 


OPERATION  AND  MAINTENANCE  COSTS 


Year 

Number  of 
sites  installed 
(cumulative) 

Operation 

($000) 

Software 

maintenance 

($000) 

Hardware 

maintenance 

($000) 

Total 

($000) 

1 

0 

0 

0 

0 

0 

2 

5 

680 

970 

130 

1,780 

3 

30 

4,082 

970 

780 

5,832 

4 

60 

8,165 

970 

1,560 

10,695 

5 

100 

13,608 

970 

17,178 

6 

100 

13,608 

970 

2,600 

17,178 

7 

100 

13,608 

970 

2,600 

17,178 

8 

100 

13,608 

970 

2,600 

17,178 

9 

100 

13,608 

970 

2,600 

17,178 

10 

100 

13,608 

970 

2,600 

17,178 

Total 

94,575 

8,730 

18,070 

121,375 

TABLE  2-11 

TOTAL  LIFE-CYCLE  COSTS 


2.8  REVIEW  OF  SYSTEM  BENEFITS 
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The  LGN  architecture  offers  many  significant  benefits  over  the  existing 
system.  Some  are  unique  to  the  LGN  architecture  in  that  they  could  not  be  provided 
in  any  other  manner,  while  others  could  also  be  provided  through  a  functional 
expansion  of  the  DAAS  configuration  although  in  some  cases  not  as  efficiently. 

2.8.1  Unique  Benefits 

The  three  benefits  unique  to  the  LGN  architecture  include:  (l)a  significant 
reduction  in  vulnerability,  (2)  elimination  of  the  need  for  duplicate  data  transmis¬ 
sion,  and  (3)  expandability. 

2.8. 1. 1  Reduction  in  Vulnerability 

Vulnerability  is  reduced  by  eliminating  those  critical  functions  at  a  central 
location  which,  if  disabled,  would  significantly  degrade  the  effectiveness  of  the 
defense  logistics  system.  The  LGN  design  eliminates  the  need  for  a  critical  central 
facility  by  distributing  all  critical  functional  capabilities  to  each  of  the  100  sites. 
Thus,  the  system  will  remain  fully  operational  in  the  event  of  a  Central  LGN  failure, 
and  the  vulnerability  of  the  LGN  system  is  equivalent  to  the  vulnerability  of  its 
individual  sites.  A  high  level  of  reliability  is  provided  at  each  site  through  the  use  of 
redundant  processors,  data  base  back-ups,  and  the  ability  of  each  LGN  to  provide 
back-up  support  to  other  sites. 

2.8. 1.2  Reduction  in  Data  Communications  Traffic 

The  LGN  system  eliminates  duplicate  data  communications  traffic  by 
supporting  direct  user/LGN  site-to-user/LGN  site  transmissions  without  requiring 
communications  with  an  intermediate  (DAAS)  site.  This  feature  will  significantly 
reduce  DoD  data  communications  costs  because  of  the  magnitude  of  present  and 
future  logistics  data  traffic.  Significant  increases  in  traffic  are  anticipated  during 
the  next  10  years  as  modernized  logistics  systems  are  implemented  and  graphics 
data  are  transmitted.  The  potential  reduction  in  traffic  by  almost  a  factor  of  two 
represents  a  significant  benefit  to  the  defense  communications  community. 


Additional  reductions  in  data  communications  traffic  would  result  from  the 
fact  that  many  inquiries  that  are  currently  forwarded  to  DAAS  can  be  served  by  the 
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local  LGN  without  requiring  data  transmission.  Examples  include  billing  history 
inquiries. 

Still  further  reductions  in  data  communications  traffic  are  provided  by  the  fact 
that  transaction  editing  is  performed  at  the  originating  LGN.  As  a  result,  incorrect 
transactions  will  not  enter  the  data  communications  system. 

While  it  would  appear  that  the  need  to  provide  frequent  updates  of  the  LGN 
files  at  each  major  logistics  site  tends  to  offset  some  of  this  benefit,  it  must  be 
recognized  that  the  DAASO  is  currently  transmitting  data  base  updates  to  more 
than  200  different  sites,  including  most,  if  not  all,  of  the  sites  at  which  the  LGNs  are 
to  be  installed.  Therefore,  the  need  for  data  base  updates  is  not  expected  to  affect  the 
projected  communications  benefits. 

It  might  also  appear  that  the  need  for  communications  between  the  satellite 
facilities  and  the  remote  LGNs  that  serve  them  would  tend  to  reduce  the  overall 
communications  benefits  since  the  traffic  for  these  sites  would  still  require  retrans¬ 
mission  (satellite  facility  to  originating  LGN  to  destination  LGN).  However,  the 
traffic  generated  by  these  sites  is  less  than  15  percent  of  the  total  logistics  traffic. 
Thus,  the  need  for  retransmission  for  these  sites  would  reduce  the  overall  benefits  by 
a  relatively  small  amount. 

2.8.1. 3  Expandability 

The  LGN  architecture  can  be  readily  expanded  to  accommodate  changes  in 
logistics  communications  at  an  individual  site  or  throughout  the  system.  If  the  size 
of  an  individual  site  were  to  increase  rapidly  (for  example,  as  the  result  of  a 
mobilization),  the  LGN  at  that  site  could  be  expanded  to  meet  its  requirements 
without  affecting  other  elements  of  the  system.  If  a  new  site  were  to  be  created  with 
adequate  logistics  traffic  to  justify  the  installation  of  an  LGN,  such  capability  could 
be  rapidly  provided.  Thus,  the  LGN  architecture  is  ideally  suited  to  the  require¬ 
ments  of  DoD  for  a  flexible  system  that  can  be  adapted  to  a  variety  of  requirements 
which  are  difficult  to  predict.  The  system  could  be  expanded  both  in  CONUS  and 
OCONUS  as  dictated  by  the  specific  situation.  This  capability  can  be  provided 
without  requiring  expensive  hardware  and  software  modifications  at  a  major  central 
data  processing  installation.  Although  not  specifically  addressed  in  this  report,  a 


deployable  version  of  the  LGN  could  be  developed.  The  availability  of  that  capability 
further  increases  the  flexibility  of  the  concept. 

2.8.2  Functional  Expansion 
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The  LGN  architecture  has  been  developed  to  take  advantage  of  the  benefits  of  a 
distributed  system.  These  advantages  include  the  ability  to  capture  and  store  data 
at  the  point  at  which  it  is  generated  and  the  ability  to  tailor  the  LGN  to  the  require¬ 
ments  of  the  local  site.  This  approach  has  produced  a  number  of  functional 
capabilities  including: 

•  The  ability  to  modify  the  LGN  data  base  to  accommodate  the  requirements 
of  the  organization  it  supports.  This  capability  reduces  the  need  to  delay 
DLSS  changes  until  all  user  computer  software  packages  can  be  updated. 

•  The  ability  to  provide  requisition  tracking  capability  throughout  the  supply 
system  using  standard  transaction  formats.  The  tracking  capability 
includes  searching  multiple  LGN  and  user  computer  data  bases. 

•  Interconnection  with  all  elements  of  the  logistics  supply,  transportation, 
contracting,  and  financial  communities.  This  includes  interface  capabilities 
to  commercial  organizations. 

•  The  ability  to  respond  to  ad  hoc  requests  for  data  from  senior  level  defense 
personnel.  This  capability  includes  the  ability  for  limited  interrogation  of 
user  system  data  bases. 

•  The  use  of  a  common  transmission  format.  The  complexity  of  the  existing 
DAAS  processing  is,  in  part,  the  result  of  the  requirement  to  provide 
compatibility  between  all  possible  combinations  of  originating  and 
receiving  sites.  The  use  of  a  common  transmission  format  eliminates  this 
complexity  since  each  LGN  must  only  provide  compatibility  between  its 
user  site  and  a  common  DLSS  format.  This  approach  simplifies  the  data 
reformatting  procedure  and  provides  the  opportunity  for  the  LGN  to  be 
responsive  to  the  unique  requirements  of  the  organization  it  serves. 

•  The  capability  for  enhancing  the  priority  system  through  automatic 
calculation  of  requisition  and  transportation  priorities  using  the  urgency  of 
need,  the  F  AD  of  the  user  organization,  and  the  RDD. 

•  The  ability  to  merge  separate  data  bases  or  to  enter  data  on  line  to 
accommodate  the  requirement  for  data  entries  on  new  DLSS  transactions 
that  cannot  be  provided  by  the  existing  user  system  software.  This  process 
can  be  implemented  at  the  local  site.  (It  would  be  difficult  to  implement  at  a 
site  remote  from  the  source  of  the  supplementary  data.) 
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•  The  ability  to  process  a  higher  percentage  of  logistics  traffic.  The 
installation  of  the  LGNs  at  major  user  sites  and  the  use  of  variable-length 
transaction  formats  will  encourage  their  use  for  all  inter-S/A  logistics 
communications  traffic.  The  ability  to  process  a  higher  percentage  of 
logistics  traffic  than  is  currently  processed  by  DAAS  will  improve  the 
quality  of  the  data  that  are  used  in  the  preparation  of  logistics  system 
performance  reports. 

Perhaps  the  most  significant  benefit  is  the  availability  of  an  architecture  that 
can  provide  these  enhanced  functions  without  any  loss  of  the  existing  system’s 
functionality.  In  addition,  these  functions  can  be  provided  at  a  cost  that  is  equiv¬ 
alent  to  the  cost  of  implementing  a  third  DAAS  site,  a  measure  that  is  being 
considered  to  reduce  the  vulnerability  that  exists  with  only  two  sites. 

The  proposed  architecture  has  been  informally  reviewed  with  representatives 
of  the  data  processing  industry.  They  believe  that  the  LGN  architecture  can  be 
implemented  using  existing  hardware  and  software  technology.  Thus,  little  risk  is 
associated  with  its  implementation. 

However,  the  viability  of  this  architecture  is  the  result  of  the  simplicity  of  the 
design  concept  that  results  from  the  use  of  standard  transaction  formats  for  user 
inquiries,  and  the  use  of  a  common  DBMS  package  on  all  LGNs.  Deviation  from 
these  concepts  could  significantly  increase  the  complexity  of  the  design. 


SECTION  3 


MODELS  IMPLEMENTATION  PLAN 


3.1  DEFENSE  LOGISTICS  STANDARD  SYSTEMS  FIVE-YEAR  MODERNIZATION 
PLAN 


3.1.1  Introduction 


The  Military  Services  and  DLA  are  modernizing  their  logistics  operational  and 
management  information  systems.  They  are  replacing  obsolete  hardware  and 
software  with  new  data  processing  and  telecommunications  technologies.  To  make 
effective  use  of  the  capabilities  of  these  new  technology  systems  throughout  the  DoD 
and  to  maintain  DoD-wide  standardization  of  logistics  information  communications, 
OASD  [Acquisition  and  Logistics  (A&L)]  directed  the  modernization  of  the  DLSS, 
which  are  defined  by  DoD  Directive  4000.25,  Administration  of  Defense  Logistics 
Standard  Systems. 


These  DLSS,  administered  by  the  Defense  Logistics  Standard  Systems  Office 
(DLSSO),  encompass  varying  degrees  of  the  following  logistics  functional  areas: 
cataloging,  inventory  management,  contracting,  contract  administration,  storage, 
distribution  and  redistribution  of  materiel,  transportation  and  movement,  mainte¬ 
nance,  property  disposal,  international  supply  support,  integrated  support  of 
weapons,  and  billing  and  collections.  The  DLSS  also  include  the  DAAS  and  the 
ILCS.  These  latter  two  DLSS  are  operational  ADP  hardware  and  software  systems 
responsible  for,  among  other  things,  editing  and  routing  a  large  percentage  of  all 
logistics  communications  between  the  Services,  DLA,  GSA,  other  Federal  organiza¬ 
tions,  commercial  contractors,  and  foreign  customers. 


The  project  with  responsibility  for  modernization  of  these  standard  systems  is 
MODELS.  Development  of  a  5-year  modernization  plan  [MODELS  Five-Year  Plan 
(FYP)]  for  the  DLSS  is  being  performed  in  a  series  of  sequential  phases  as  follows: 


1.  Definition  of  the  existing  logistics  system  and  modernization  efforts  in  the 
Services  and  DLA 


2.  Analysis  of  functional  and  technological  requirements 


3.  Development  of  operating  concepts  and  a  MODELS  implementation 
strategy  and  plan 

4.  Preparation  of  a  five-year  plan  for  the  DLSS  modernization,  both  func 
tional  and  operational. 

3.1.2  Purpose 

The  DLSS  modernization  will  be  based  on  a  simultaneous,  two-pronged  effort 
involving:  (1)  functional  modernization  —  updating  and  expanding  procedures  and 
transactions  used  in  communicating  logistics  information  and  (2)  technical 
modernization  —  improving  the  capabilities  of  the  hardware  and  software  used  in 
the  various  information  routing  processes. 

3.1.3  Summary 


3. 1.3. 1  Modernizing  DLSS  Procedures  and  Transactions 

MODELS  will  increase  the  depth  and  breadth  of  logistics  operational  and 
management  functions.  Included  are  the  further  definition  and  enhancement  of  the 
DoD-wide  standard  logistics  data  element  dictionary  [Logistics  Data  Element 
Standard  Dictionary  (LOGDESD)]  along  with  a  comprehensive  data  source- 
destination  directory.  The  functional  modernization  incorporates  current  DLSS 
policies,  procedures,  and  transactions  realignments,  and  transactions  redesign  to 
accommodate  varying  amounts  of  information.  The  realignment  of  DLSS  procedures 
will  adjust  to  functional  lines  of  operation  and  responsibility  as  depicted  in  the 
information  flow  diagrams  presented  in  Section  1.  The  transactions  redesign  may  be 
based  upon  EDI  concepts  and  standards  incorporating  variable-length  fields  and 
records. 

3. 1.3.2  Modernizing  DLSS  Communication  Technologies 

MODELS  is  based  on  current  and  evolving  data  management  and  telecom¬ 
munications  capabilities.  The  basis  of  the  modernization  is  an  LGN  architecture 
with  processors  at  major  logistics  sites.  The  LGNs  can  translate  transactions  from 
S/A  internal  system  (intra-Service)  formats  to  an  EDI-based  DoD  DLSS  standard 
format.  The  LGNs  are  linked  through  a  centrally  owned  and  managed  wide-area 
network  (DDN)  that  permits  central  updating  and  information  management 
reporting.  However,  logistics  operational  information  would  be  communicated 


directly  from  source  to  destination  and  all  critical  logistics  management  functions 
reside  at  the  LGN. 


m 


3. 1.3. 3  Resource  Requirements 

MODELS  estimated  resources  do  not  specifically  identify  the  source  of  the 
labor.  The  efforts  must  be  coordinated  tasks  involving  OSD,  DLSSO,  DAASO,  the 
Services  and  Agencies,  and  commercial  contractors. 

3. 1.3. 4  Strategic  Plan 

The  initial  5-year  strategic  plan  for  modernization  of  the  DLSS  is  shown  in 
Figure  3-1.  In  that  figure,  each  circled  item  is  a  major  project  to  be  performed,  the 
#-F  projects  are  functional  modernizations,  the  #-S  projects  are  technology 
improvements,  and  the  Arabic  numbers  associated  with  each  project  are  the 
recommended  sequence  for  performance.  However,  projects  can  be  performed 
simultaneously,  as  depicted  by  the  concurrent  schedules.  The  remainder  of  this 
section  describes  the  objectives  of  each  major  project  along  with  the  actions  that 
should  be  completed  during  the  scheduled  period. 

Appendix  B.  "Models  Functional  Requirements  in  Implementation  Priority 
Groupings,”  presents  the  MODELS  recommendations.1 

3.2  MODERNIZING  DEFENSE  LOGISTICS  STANDARD  SYSTEMS  PROCEDURES  AND 
TRANSACTIONS 

3.2.1  Objectives 

The  strategies  for  modernization  of  DLSS  procedures  and  transactions  have  the 
following  four  objectives: 

1.  Establish  direct  relationships  between  modernized  DLSS  procedures  and 
operational  logistics  functions .  This  objective  includes  identifying 
overlaps,  duplication,  gaps,  and  misalignments  between  DLSS  procedures 
and  functional  opera tions. 

2.  Institute  variable-length  transaction  formats  as  the  basis  for  logistics 
information  interchange  The  concepts  and  methodologies  developed  for 
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MODELS  FIVE-YEAR  PLAN  PROJECTS  SCHEDULE 


the  commercial  sector  EDI  standards  will  serve  as  the  basis  for  this 
definition. 

3.  Review  and  revise  DLSS  procedures.  The  modernization  of  DLSS 
operational  procedures  must  specifically  address  identifying  those  docu 
ments  that  must  be  reassigned  to  a  different  DLSS  as  a  result  of  revising 
the  organization  of,  or  alignment  of,  current  procedures;  revising  and 
consolidating  documents  and  reducing  data  in  order  to  implement 
procedures  using  the  capabilities  of  the  variable-length  transaction 
formats;  and  identifying  opportunities  for  the  consolidation  of  Service- 
unique  documents  into  revised  DLSS  documents. 

4.  Transition  to  modernized  DLSS.  A  transition  plan  is  required  to  identify 
the  manner  in  which  the  modernized  DLSS  should  be  implemented.  It 
must  define  procedures  for  translating  existing  fixed-length  transactions 
into  revised  variable-length  transactions  for  organizations  that  will  not 
have  the  capability  to  process  the  new,  variable-length  formats  when  the 
transactions  are  ready  for  DoD-wide  adoption.  It  must  also  outline 
methods  for  smooth  changeover  from  the  old  to  the  new  DLSS  procedures 
and  transactions  without  mission  disruption.  These  methods  must  be 
closely  coordinated  with  Service  and  Agency  functional  and  ADP  staffs. 

3.2.2  Summary  of  Variable-Length  Concept  and  Electronic  Data  Interchange 
Relationship 

A  key  limitation  to  the  effective  communication  and  processing  of  logistics 
information,  that  has  been  continually  cited  at  Congressional  hearings  and  Major 
Automated  Information  System  Review  Council  (MAISRC)  meetings,  is  the  obsolete 
techniques  associated  with  the  use  of  the  "80-column  card  format."  Names  of  parts, 
vendor  P'Ns,  DoDAAC  or  in-the-clear  organization  ship-to  and  bill-to  names  and 
addresses,  order  quantities,  special  instructions,  contractual  information, 
transportation  information,  etc.,  all  vary  in  length.  To  use  fixed  length  records  to 
accommodate  maximum  lengths  without  truncation  is  extremely  inefficient  for  data 
coding  and  telecommunication. 

EDI  standards  are  already  developed  or  actively  under  development  for  many 
commercial  business  transactions  such  as  purchase  orders  and  acknowledgments, 
status  inquiries  and  reports,  shipping  notices,  receiving  advice,  invoices,  requests  for 
quotations,  reply  to  quotations,  etc.  While  formats  for  DoD  EDI  standards  may  not 
necessarily  be  identical  with  those  of  their  commercial  counterparts,  such  similar 
concepts  as  logical  grouping  of  data  elements  into  small  discrete  data  segments  can 
be  used. 


Within  the  data  segment,  data  element  lengths  may  vary  in  size.  For  example, 
a  small  or  specialized  vendor's  P  N  may  only  be  three  or  four  positions  long. 
However,  a  large  international  parts  distributor  may  use  P  Ns  of  20  to  30  positions. 
The  data  field  parameters  should  accommodate  both  parts  without  having  to  be  fixed 
to  the  largest  possible  number. 

3.2.3  Implementation  Strategies 

The  strategy  for  implementing  recommended  changes  to  the  DLSS  summarized 
in  Appendix  B  of  this  report,  is  to  subdivide  the  recommendations  into  three  priority 
groupings  as  follows: 

•  Current  DLSS  procedures  and  associated  transactions,  [e.g.,  MILSTRIP. 
Military  Standard  Transaction  Reporting  and  Accounting  Procedures 
(MILSTRAP),  existing  coverage  in  Military  Standard  Contract 
Administration  Procedures  (MILSCAP)  and  Military  Standard 
Transportation  and  Movement  Procedures  (MILSTAMP),  etc.] 

•  Expanded,  current  DLSS  procedural  areas  and  closely  associated  supply 
operations  and  supply  information  management  interfaces  [e.g.,  expanded 
MILSCAP  encompassing  a  fuller  scope  of  acquisition  and  contract 
administration  procedures,  worldwide  transportation  procedures  under 
MILSTAMP,  Weapons  System  Manager  (WSM)  procedures,  and  expanded 
functional  performance  measurements,  i.e.,  MILSTEP-type  procedures] 

•  Expanded  logistics  system  interfaces  into  functional  areas  not  presently 
within  the  DLSS  scope  (e.g.,  supply-item  technical  data  management, 
requirements  planning  and  analysis  for  supply  managed  items,  and  supply- 
maintenance  information  electronic  interfaces). 

This  subdivision  of  projects  is  shown  in  the  MODELS  Five-year  Plan  Projects 
Schedule  in  Figure  3-1. 

3.2.4  First  Procedures  Modernization 

The  first  project  (1-F)  under  the  DLSS  transactions  modernization  program  is 
to  convert  the  400-plus  current  DLSS  transaction  formats  in  the  procedures 
encompassed  by  Department  of  Defense  Instruction  ( DoDI)  4000.25  and  to  consoli 
date/reorganize  them  into  variable-length  formats. 

Within  this  project,  a  series  of  activities  must  be  successfully  completed  before 
the  MODELS  transactions  can  be  defined  and  implemented.  Those  activities  are 
similar  for  the  development  of  variable-length  transactions  within  each  of  the 


priority  groupings.  The  activities  for  the  initial  set  of  MODELS  transactions 
development,  described  below,  applies  in  general  to  all  transactions. 


The  first  task  is  defining  and  developing  a  DoD  LOGDESD.  This  dictionary  is 
based  on  the  present  DoD  Logistics  Data  Element  Standardization  and  Management 
Program  (LOGDESMAP)  DoDI  4000.25-13  and  its  Logistics  Data  Resource 
Management  System  (LOGDRMS).  To  them  are  added  the  EDI  data  element 
definitions  and  code  list  dictionary.  This  addition  involves  an  examination  and 
comparison  of  terms  and  definitions  to  identify  and  annotate  matching  data 
elements  to  resolve  which  of  the  competing  terms  is  to  be  the  standard.  The  merging 
and  integration  of  LOGDRMS  and  EDT  data  element  sets  is  illustrated  in  Figure  3  2. 


FIG.  3-2.  DEVELOPMENT  OF  A  DoD  STANDARD  DICTIONARY  OF  LOGISTICS  DATA  ELEMENTS 


The  LOGDESD  will  be  an  interactive  system  permitting  easy  access  and 
retrieval  of  information.  Its  data  base  will  include  every  data  element  of  the  existing 
DLSS  standards,  existing  Service-unique  transaction  data  elements  within  the 
prescribed  DLSS  functional  areas,  and  the  EDI  data  elements  in  the  pertinent  DLSS 
functional  areas.  The  specific  activities  associated  with  the  development  of  this  data 
base  should  include: 

•  Analyzing  LOGDRMS  and  EDI  data  base  formats  and  data  elements  for 
applicability  and  adaptability  to  data  base  requirements 

•  Defining  data  base  organization,  data  base  contents,  and  sources  of 
information 

•  Selecting  computer  equipment  and  DBMS  software  to  support  creation  and 
use  of  the  DoD  LOGDESD  data  base 

•  Create  LOGDESD. 

The  second  task  that  must  be  conducted  concurrently  with  the  data  element 
dictionary  development  is  the  definition  and  development  of  the  modernized  DLSS 
logistics  operations  model  and  the  resolution  of  any  issues  resulting  from  proposed 
operational  changes.  This  process  is  the  basis  for  the  data  element  data  base 
configuration  and  its  subsequent  management. 

Five  activities  define  the  modernized  DLSS  operational  model.  They  consist  of 
identifying  and  defining: 

1.  The  relevant  logistics  functional  systems  and  the  scope  of  their  application 
(e.g.,  inventory  control  between  ICPs  and  supporting  depots,  shipment 
status  between  depot  and  customer) 

2.  The  applicable  subsystems  (e.g.,  MRO  and  acknowledgment:  materiel 
release  acceptance,  denial,  or  passing  confirmation,  and  confirmation 
acknowledgment;  shipment  status  and  current  location  tracing) 

3.  The  applicable  logistics  operations  and  information  processes  (e.g..  item 
inventory  data  base  inquiry,  MRO  preparation,  hazardous  material 
shipment  instructions,  contract  administration  award  notification) 

4.  Transaction  data  requirements,  both  interactive  and  batch  (e.g.,  inventory 
inquiry,  item  procurement  inquiry,  in-transit  shipment  location  and 
delivery  date  inquiry) 
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5.  Transaction  data  fields  (data  segments)  to  be  included  in  variable-length 
standardized  transactions  (e.g.,  item  identifiers,  SOS,  destination  of 
supply,  delivery  priority  requirements). 

The  third  task  of  this  project  is  to  realign  existing  DLSS  procedures  to  enhance 
management  efficiency.  The  results  of  this  task  are  not  expected  to  cause  major 
changes  in  the  existing  DLSS.  Rather,  they  are  expected  to  modify  the  scope  of  the 
existing  DLSS  by  adding  and  deleting  transactions. 

This  task  requires  frequent  reviews  with  the  DLSSO  administrators  and 
Service  representatives  to:  (1)  verify  the  accuracy  and  relevance  of  the  results  being 
produced  and  (2)  evaluate  the  impact  of  recommended  realignments  on  Service  and 
Agency  intraorganizational  systems  and  procedures. 

The  fourth  task  is  to  define  and  develop  transactions  in  the  variable-length 
format  to  minimize  duplicative  processing  and  communications  requirements  and  to 
maximize  consistency  within  the  new  alignment  of  the  DLSS.  The  variable-length 
formats  must  be  compatible  with  the  DLSS  functional  operations  requirements, 
must  consider  transition  from  the  existing  formats,  and  must  incorporate  the  unique 
requirements  of  the  individual  Services  and  DLA  where  appropriate.  To  successfully 
accomplish  this  task  it  is  necessary  to: 

•  Define  logistics  information  sources  and  destinations,  describe  the  flow  of 
information  between  the  organizations,  and  segregate  the  information  into 
logical  transaction  sets. 

•  Develop  a  list  of  the  transactions.  This  list  will  be  a  subset  of  the  existing 
list  of  transactions  since  a  single  variable-length  format  is  capable  of 
accommodating  multiple  sets  of  existing  transactions.  For  example,  there 
are  presently  eight  requisition  formats  (AO  series  documents)  that  differ 
because  of  minor  variations  in  information  content.  These  documents  could 
conceivably  be  simplified  as  a  single  variable-length  requisition  trans¬ 
action. 

•  Define  the  overall  structure  of  each  transaction  in  terms  of  the  data 
segments  it  contains  and  Service  and  DLA  unique  information  require¬ 
ments. 

•  Define  the  data  elements  that  make  up  each  data  segment  in  terms  of  the 
type  (numeric,  alphanumeric,  etc.),  ranges  of  values,  types  of  values, 
definition  of  contents,  and  the  identification  and  description  of  relationships 
with  information  in  other  fields. 


As  with  the  previous  task,  this  task  requires  frequent  reviews  with  the  DLSSO 
administrators  and  S/A  representatives  to  verify  the  accuracy  and  relevance  of  the 
results  being  produced  and  to  evaluate  the  impact  of  recommended  formats  on  S/A 
intraorganizational  systems  and  procedures. 

The  fifth  task  of  the  modernized  DLSS  transactions  development  project  is 
documentation  of  the  revised  DLSS  procedures  and  their  associated  variable-length 
transactions.  This  documentation  must  include  references  to  the  existing  DLSS 
procedures,  describing  changes  and  realignments  that  have  been  made  and 
providing  a  map  from  existing  formats  to  modernized  variable-length  formats.  Also, 
existing  procedures  must  be  rewritten  into  a  form  and  format  for  the  modernized 
DLSS  procedures  and  be  formally  issued  as  DoD  manuals  and  regulations. 

The  sixth  and  final  task  of  this  project  is  actual  testing  of  the  modernized 
variable-length  DLSS  transactions.  This  will  occur  during  the  prototype  testing  of 
the  LGN  architecture.  The  new  transactions  will  be  used  during  a  6-month  live  test 
described  in  the  next  section. 

3.2.5  Phase  2  and  3  Defense  Logistics  Standard  Systems  Transaction  Development 
Projects 

As  indicated  in  Figure  3-1,  two  additional  transaction  development  projects 
must  be  performed  to  address  the  full  scope  of  future  DLSS  procedures.  These 
projects  will  be  conducted  in  a  similar  manner  to  the  first  implementation  step  just 
described.  However,  one  major  additional  task,  policy  formulation,  must  first  be 
taken. 

Because  the  first  implementation  addresses  only  existing  DLSS  procedures, 
only  a  few  policy  issues  need  to  be  addressed.  However,  as  DLSS  procedures  and 
transactions  are  expanded,  major  issues  will  have  to  be  considered  and  resolved. 
These  issues  include  the:  ( 1)  degree  of  and  the  manner  of  interaction  with  existing 
DoD  component  logistics  systems,  (2)  responsibilities  of  administrative  and  opera¬ 
tional  organizations,  (3)  scope  of  expanded  procedures,  (4)  availability  and  sources  of 
logistics  information  to  be  included,  and  (5)  cost-benefit  of  expanded  information 
requirements.  Thus,  the  first  task  of  these  subsequent  projects  is  to  identify, 
formulate,  and  resolve  the  policy  issues  related  to  the  expanded  scope  of  DLSS. 
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Successful  accomplishment  of  this  first  task  will  require  not  only  frequent  and 
close  coordination  with  functional  and  operational  working  groups  from  the  Services 
and  Agencies  but  also  careful  review  and  recommendations  by  a  senior-level 
management  board  comprised  of  representatives  from  OSD,  the  Services,  affected 
Agencies,  and  the  JCS  community. 

3.3  STRATEGIES  FOR  MODERNIZING  DEFENSE  LOGISTICS  STANDARD  SYSTEMS 

COMMUNICATION  TECHNOLOGIES 

3.3.1  Objectives 

In  today's  logistics  environment,  the  ability  of  the  defense  logistics  community 
to  operate  effectively  in  a  changing  technological  environment  depends  on  the 
quality  of  service  provided  by  the  inter-Service  logistics  information  communication 
system. 

The  existing  inter-Service  and  Agency  logistics  information  communication 
system  consists  of  two  DAAS  facilities  that  perform  much  of  the  routing  and 
translation  functions  required  to  achieve  interoperability  among  the  various  Service 
and  Agency  logistics  processing  systems.2  This  communication  architecture  is  based 
upon  centralized  data  base  concepts  that  have  inherent  functional  and  operational 
vulnerability.  The  current  DAAS  hardware  and  software  designs  are  obsolete  and 
are  being  modernized  under  the  DARP,  but  they  are  still  based  upon  centralized  data 
communications  and  data  base  storage  concepts. 

During  the  next  10  years,  logistics  data  communications  traffic  is  expected  to 
grow  significantly  as  a  result  of  normal  increases  in  logistics  traffic,  new  require¬ 
ments  for  data  transmissions  between  facilities,  expanded  ADP  (e.g.,  increasing 
automation  of  acquisition  processing  and  monitoring  activities),  and  increased 
integration  of  logistics  functions  (e.g.,  automated  interfaces  between  supply  and 
maintenance).  Another  significant  change  will  be  increasing  pressure  for 
interactive  access  to  logistics  information  (e.g.,  item  availability  and  in-transit 
status),  as  more  persons  become  familiar  with  and  have  access  to  microcomputers 
and  work  stations. 


-Not  all  DESS  transactions  are  communicated  through  DAAS  Examples  of  transactions 
that  are  presently  transmitted  direct  from  source  to  destination  are  MII.SCAP  and  some 
MIESTA.MP  transactions.  Under  the  MODELS  concept,  all  1)1. SS  transactions  would  he 
communicated  through  the  LGNs 
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The  inefficiencies  in  cost  (i.e.,  double  transmission  cost  of  most  logistics 
transactions,  once  from  source  to  DAAS  and  a  second  time  from  DAAS  to  destina 
tion)  and  time  (i.e.,  that  needed  to  regroup  and  retransmit  transactions  at  a 
centralized  DAAS  facility)  are  unacceptable  in  a  system  projected  to  grow  by  almost 
300  percent  in  the  next  decade. 

Thus,  a  new  data  communication  method  is  needed.  A  less  vulnerable,  less 
costly,  and  more  flexible  alternative  to  the  existing  logistics  communications  system 
architecture  is  needed.  An  LGN  architecture  based  on  the  use  of  a  table-driven 
DDBMS  within  a  wide-area  logistics  network  is  recommended.  This  architecture  is 
described  in  detail  in  Section  2. 

To  demonstrate  the  advantages  of  the  LGN,  a  working  prototype  should  be 
implemented.  The  prototype  will  also  identify  features  that  must  be  modified, 
deleted,  or  supplemented  in  the  conceptual  design. 


A  second  objective  of  the  prototype  test  is  the  development  ol  ietailed  estimates 
of  the  costs  and  benefits  of  implementing  the  LGN  architecture.  The  cost  estimate 
will  include  the  hardware  procurement,  software  purchase  anchor  development  and 
associated  conversion,  data  base  conversion,  and  personnel  associated  with  the  LGN 
implementation,  facilities  requirements,  communication  physical  line  installation 
costs,  and  LGN  operation  and  maintenance.  The  benefits  estimate  must  reflect  the 
expected  savings  in  communications  costs  for  source-to-destination  data  flows,  time 
reduction  savings,  and  increases  in  productivity  resulting  from  better  and  faster 
information  availability. 

The  third  objective  of  the  prototype  test  is  to  provide  the  basis  for  development 
of  a  detailed  implementation  plan  to  integrate  hardware,  software,  variable-length 
transactions,  and  revised  procedures  into  a  modernized  DLSS  system. 

3.3.2  Summary  of  the  Logistics  Gateway  Node  Concept 


The  LGN  architecture  replaces  the  two  DAAS  facilities  with  local  logistics  site 
LGNs  that  provide  an  enhanced,  distributed  version  of  most  of  the  functions 
currently  performed  by  DAAS.  The  LGN  architecture  would  be  implemented 
through  the  installation  of  front-end  processors  (LGNs)  at  the  major  logistics  sites 
including  wholesale  logistics  activities  (ICPs  and  depots),  finance  centers.  Defense 
Contract  Administration  Service  Region  (DCASR)  offices,  transportation 


management  facilities,  and  major  intermediate  retail-level  activities.  One  LGN  site 
(probably  the  Dayton,  Ohio  DAAS  site)  would  be  designated  the  Central  LGN  to 
perform  summary  reporting  and  configuration  management  functions  that  are 
required  for  overall  system  network  operations. 

The  LGNs  would  ensure  that  all  traffic  entering  the  inter-S/A  data  commu 
nications  facilities  of  the  DoD  are  consistent  with  standardized  DLSS  transaction 
formats.  Since  the  LGX  would  act  as  the  interface  between  its  user  computer(s)  and 
other  processors  of  the  defense  logistics  system,  it  can  be  tailored  to  the  requirements 
of  the  user  facility. 

Sites  that  do  not  have  a  local  LGN  would  communicate  with  the  logistics 
system  as  satellite  facilities  through  a  designated  user  site.  These  satellite  facilities 
would  therefore  have  access  to  all  of  the  LGN  features  available  at  the  user  site. 

3.3.3  Implementation  Strategies 

The  strategy  for  implementing  a  modernized  telecommunications  and  informa¬ 
tion  processing  system  to  support  the  DLSS  information  flow  requirements  pre¬ 
sented  in  Sections  1  and  2  of  this  report,  is  to: 

•  Develop  system  specifications  and  conduct  a  prototype  of  the  system  archi¬ 
tecture  at  selected  logistics  sites 

•  Conduct  detailed  cost-benefit  and  economic  impact  analysis  to  prove  the 
financial  practicality  of  the  LGN  concept  before  planning  full-scale  imple 
mentation 

•  Prepare  a  full-scale  implementation  plan,  that  includes  phased  implemen 
tations,  test  plans,  transition  schedules,  and  operation  and  maintenance 
plans 

•  Prepare  specifications  for  a  competitive  request  for  proposal  (RFP)  for  the 
implementation  of  the  LGN  network  and  conduct  the  competitive  procure¬ 
ment 

•  Install,  test,  and  implement  the  modernized  DLSS  procedures  using 
modernized  communications  and  processing  LGNs. 

This  phased  development  and  implementation  is  shown  in  Figure  3- 1  under  the 
System  LGN  Requirements  subsection.  The  actual  plan  extends  over  12  years  (to 


1998)  before  the  LGN  architecture  is  fully  implemented  and  operational.  This  is  a 
tight  schedule  considering  the  many  major  activities  that  must  be  accomplished. 

3.3.4  System  Architecture  Prototype 

The  first  step  under  the  LGN  network  implementation  program  is  to  select  a 
few  major  logistics  sites  at  which  to  conduct  a  small  but  comprehensive  testing  of 
hardware  and  software  prototypes  and  modernized  DLSS  transactions  and  proce¬ 
dures.  The  activities  to  be  performed  during  the  first  project  include: 

•  Developing  detailed  hardware  and  software  specifications  to  support  the 
prototype  tests 

•  Selecting  the  logistics  sites  for  the  prototypes 

•  Preparing  the  prototype  test  plans 

•  Acquiring  prototype  systems  (hardware  and  software)  and  providing 
necessary  support  to,  and  monitoring  of,  their  installation  at  each  site 

•  Conducting  a  6-month  prototype  test  using  MODELS  transaction  formats 

•  Evaluating  the  prototype  test  and  developing  recommendations  for  changes 
and  improvements  to  the  LGN  requirements  and  specifications 

•  Preparing  a  final  detailed  functional  description  of  the  LGN  concept  and 
revised  functional  specifications. 

3.3.4. 1  Developing  LGN  Requirements 

As  a  first  task  of  this  project,  the  hardware  and  software  requirements  for  the 
working  prototype  must  be  defined  for  the  overall  system  level  and  for  the  unique 
requirements  of  each  selected  site.  The  definition  should  include  specifications  for 
the  processor,  peripheral  equipment,  communications  interface  hardware  and 
associated  protocol  requirements  (e.g.,  standard  communication  interfaces),  the 
capabilities  of  the  DBMS  package,  and  any  special-purpose  software  required  for  the 
test.  The  requirements  should  also  contain  a  description  of  the  data  bases  that  are 
required  to  support  the  system  operational  test  and  evaluation. 

A  functional  definition  of  the  prototype  system  will  be  prepared.  That 
definition  should  provide  a  summary  system  description:  operating  requirements: 
test  conduct  details  including  inputs,  processing,  and  outputs;  a  definition  of  the 
operating  environments  at  the  various  sites:  and  estimates  of  the  prototype 


implementation  and  test  conduct  costs.  This  functional  definition  for  the  prototype 
systems  and  their  environments  should  be  prepared  in  the  general  form  of  an  RFP  to 
ensure  that  the  commercial  vendors  selected  to  provide  the  various  hardware  and 
software  have  a  specification  to  work  with  in  preparing  their  technical  and  cost 
proposals. 

The  functional  definition  document  must  be  a  working  document  that  can  be 
revised  as  the  prototype  is  implemented  and  the  evaluation  conducted. 

3. 3. 4.2  Selecting  Prototype  Sites 

The  prototype  test  is  currently  planned  to  be  conducted  at  three  operational 
logistics  sites  and  a  Central  LGN  site  (DAASO).  To  optimize  the  transaction  testing 
activities  (i.e.,  test  the  largest  number  of  different  transactions  possible),  the 
operational  sites  should  probably  include  a  major  retail  operation,  an  ICP,  and  a 
depot.  Final  decisions  as  to  the  types  of  functional  sites,  their  specific  locations,  and 
related  information  will  be  based  upon  site  selection  criteria.  It  is  important  that 
this  activity  be  performed  early  in  the  project  because  the  types  of  sites,  and 
therefore  the  DLSS  transactions  to  be  used  during  the  prototype  test,  will  establish 
priorities  for  the  transactions  design  project. 

3. 3. 4.3  Preparing  the  Prototype  Test  Plan 

After  the  sites  are  identified,  a  test  specification  and  plan  will  be  developed  to 
more  fully  define: 

•  Objectives  of  the  test  and  the  criteria  by  which  the  success  of  the  test  is  to  be 
determined 

•  Functions  and  processing  capabilities  'f  each  test  site  LGN 

•  Specific  software  processing  and  data  base  requirements  at  each  LGN  to 
support  the  test 

•  Staffing  requirements  for  each  site,  including  the  number,  type,  and  source 
of  personnel 

•  Schedules  for  installing  the  equipment,  testing  it.  and  evaluating  the  test  at 
each  site:  that  is,  schedules  to  identify  milestones  for  each  responsible 
organization  to  complete  their  respective  assignments. 


Preliminary  prototype  test  planning  anticipates  that  the  operational  test 
scenario  will  be  similar  to  the  following: 

•  Thirty-day  test  of  variable-length  test  transactions  designed  to  provide  a 
robust  test  of  the  full  range  of  transaction  types. 

•  Sixty-day  test  of  transactions  from  the  selected  prototype  sites,  collected 
over  a  prior  6-month  period.  Transactions  will  be  in  current  DLSS  format 
and  converted  by  the  LGN  to  new  variable-length  formats  for  transmission. 

•  Ninety-day  live  operations  from  and  to  each  of  the  designated  prototype 
sites  (modified  DAAS  storage  of  transactions  for  parallel  operations)  with 
actual  DLSS  logistics  transactions  in  current  formats  converted  to  new 
formats  by  the  LGN. 

The  portion  of  the  test  plan  developed  for  the  evaluation  of  prototype  effec¬ 
tiveness  must  include  both  qualitative  and  quantitative  assessments  of  the  LGN's 
effectiveness. 

The  qualitative  assessment  should  include  interviews  with  systems  and 
logistics  personnel  at  both  the  midpoint  and  conclusion  of  the  test  period.  The 
assessment  must  obtain  their  evaluation  of  positive  and  negative  aspects  of  the 
LGN’s  operation. 

The  quantitative  assessment  must  be  maintained  in  the  form  of  a  system 
operating  log  to  annotate  various  characteristics  and  problems  associated  with 
performance.  One  component  should  be  before  and  after  evaluations  of  logistics 
operations.  The  ’'before"  case  would  consist  of  system  performance  measurements 
conducted  with  the  existing  logistics  system  architecture  using  the  DAAS  facilities: 
the  "after”  case  would  evaluate  system  performance  during  the  test  period  while  the 
LGN  is  installed  and  operating.  The  quantitative  operating  parameters  to  be 
collected  during  these  two  test  periods  would  include  measures  such  as  system 
response  times,  communications  message  traffic  volumes  and  message  lengths,  error 
rates,  number  of  lost  documents,  number  of  erroneous  documents,  etc.  Quantitative 
measures  must  also  include  the  personnel  required  (i.e.,  number  and  skill  level)  to 
support  each  mode  of  logistics  system  operation. 

The  test  plan  will  define  all  of  the  qualitative  and  quantitative  parameters  that 
are  to  be  evaluated  and  the  methods  of  evaluation.  This  test  plan  will  be  the  basis  for 
designing  the  actual  test  scenarios  before  conduct  of  the  6-month  prototype  test. 
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3. 3. 4.4  Acquiring  Prototype  Systems 


Using  the  functional  descriptions  and  test  plans  developed  in  the  first  stages  of 
this  project,  the  prototype  systems  will  be  acquired  [e.g.,  Government-furnished 
equipment  (GFE),  if  available,  leased,  or  purchased,  whichever  is  most 
cost-effective].  If  GFE  is  not  available,  the  following  activities  must  be  completed  ti 
acquire  the  prototype  systems: 

•  Preparing  documentation  required  to  support  and  justify  the  acquisition 

•  Conducting  a  marketplace  survey  to  identify  possible  suppliers  of  the 
prototype  equipment.  The  marketplace  survey  must  accompany  the  justifi 
cation  to  support  an  R&D  acquisition. 

•  Requesting  technical  and  cost  proposals  from  one  or  more  suppliers, 
evaluating  the  responses,  negotiating  with  the  best  offeror  as  necessary, 
and  awarding  a  contract  for  the  lease  or  buy  of  the  systems. 

Successful  development  and  implementation  ofLGN  software  will  require  that 
DAASO  staff  actively  participate  in  the  specification,  design,  and  development  of  the 
LGX  operational  applications  software,  data  base  system  software  selection,  and 
software  implementation  acceptance  testing. 

3. 3. 4.5  Conducting  a  Logistics  Data  Flow  Prototype  Test 

Installation  of  the  prototype  systems  primarily  by  the  selected  vendor  will  be 
the  first  component  activity.  All  the  installation  requirements  must  be  carefully 
reviewed  and  site  support  provided  for  floor  space,  office  space,  communications 
facilities,  and  hardware  utilities  ( heating  cooling,  electricity,  etc.).  Support  for  data 
base  conversion  and  LGX  application  software  implementation  will  probably  be 
provided  by  the  staff  at  DAASO,  which  will  serve  as  the  Central  LGX  site,  a  fourth 
LGX  test  site.  The  Central  LGX  will  be  responsible  for  local  site  LGX  configuration 
management,  broadcasting  data  base  updates  to  the  local  LGXs,  and  central  data 
collection  for  activities  such  as  aggregated  performance  measurement  summaries. 

Installation  monitoring  activities  will  include  review  of  all  installation  plans; 
review  and  approval  of  planned  system-generated  reports,  displays,  and  functional 
capabilities;  and  verification  that  the  equipment  and  software  ( both  applications  and 
special  purpose)  conform  with  the  requirements  of  the  specifications. 


The  second  component  activity  is  acceptance  and  "dry  run”  testing  of  the 
installed  hardware  and  software,  prior  to  beginning  the  6  month  prototype  opera 
tional  test. 

The  third  component  activity  is  the  actual  conduct  of  the  6-month  test.  The 
following  paragraphs  describe  briefly  the  planned  prototype  operations 

The  DAAS  facilities  will  act  as  both  the  current  central  routing  facility  for 
logistics  information  and  the  Central  LGX  configuration  control  during  the  test.  As 
the  central  routing  facility,  DAAS  will  receive  all  transactions  from  the  test  sites  not 
directed  to  another  test  site  and  route  them  to  their  appropriate  destination.  As  the 
Central  LGX.  DAAS  will  receive  updates  to  customer  addresses,  SOS  changes,  and 
requests  for  ad  hoc  reports.  It  will  send  changes  to  local  site  LGX  data  bases  or 
collect  information  from  LGX  data  bases  to  prepare  ad  hoc  reports. 

Each  local  LGX  test  site  will  prepare  logistics  transactions  in  its  normal  mode 
of  operation.  However,  instead  of  being  transmitted  from  the  base  communications 
center  to  DAAS.  the  transactions  will  go  from  the  site’s  local  computer  into  the  local 
LGX.  Within  the  LGX  the  transactions  will  be  edited  against  the  SOS  data  base  and 
separated  into  batches,  one  directed  to  DAAS  in  its  traditional  role  of  central  routing 
facility,  and  the  others  to  the  test  sites  designated  as  the  destinations  for  the 
transactions. 

In  addition,  each  site  will  continue  to  send  its  entire  set  of  logistics  transactions 
to  DAAS  using  existing  methods.  However,  those  transactions  for  another  test  site 
will  have  a  special  record  identifier  to  advise  DAAS  to  hold  the  record  rather  than 
retransmit  the  transactions  to  the  intended  destination.  This  will  be  the  back  up 
parallel  operation  for  the  test  site  and  would  immediately  be  put  into  operation 
should  difficulties  arise  with  the  LGX  test.  Thus,  the  test  will  have  a  well-defined 
and  ready  for  operation  alternative  system  to  support  the  site's  logistics  activity 
requirements. 

At  the  conclusion  of  the  6-month  test,  all  the  test  sites  will  revert  to  their 
current  mode  of  logistics  communications  operation. 

3. 3.4.6  Evaluating  the  Prototype  Test 

The  LGX  architecture  and  the  MODELS  variable-length  transactions  will  he 
evaluated  in  accordance  with  previously  developed  plans  and  criteria  established  in 


the  test  plan.  The  final  test  plan  will  be  reviewed  prior  to  commencing  the  prototype 
operational  test,  to  incorporate  any  significant  changes  that  occurred  during  the 
installation  of  the  LGN. 

The  test  plan  will  call  for  a  qualitative  and  quantitative  evaluation  of  perform¬ 
ance  at  the  three  test  sites  and  at  DAAS.  The  evaluation  will  continue  through  the 
period  of  the  test,  and  the  collected  data  will  be  analyzed  and  summarized  in  the 
6  months  following  the  conclusion  of  the  test.  The  evaluation  will  include  a 
reassessment  of  the  hardware  and  software  functional  requirements;  operational 
requirements;  implementation  and  operation  costs;  functions  of  the  Central  LGN; 
reliability,  maintainability,  and  vulnerability  issues;  and  similar  implementation 
and  operations  characteristics.  The  evaluation  will  also  include  recommendations 
for  any  changes  to  the  LGN  architecture,  implementation  plans,  and  operational 
requirements. 

3.3. 4.7  Preparing  the  LGN  Documentation 

The  last  task  of  the  prototype  evaluation  is  preparation  of  documentation  of  the 
prototype  test  procedures,  results  of  the  evaluation,  recommendations  for 
improvements,  and  updates  to  the  system  functional  description  and  specification. 
This  documentation  must  be  prepared  in  sufficient  detail  to  permit  a  full  under¬ 
standing  of  the  objectives,  purpose,  procedures,  problems,  findings,  and  recommen¬ 
dations  of  the  prototype  project. 

3.3.5  Cost-Benefit  and  Economic  Impact  Analyses 

Assuming  the  success  of  the  prototype  LGN  test,  a  cost-benefit  and  economic- 
impact  analysis  of  the  LGN  must  be  conducted  to: 

•  Prepare  for  MAISRC  milestones,  if  required 

•  Prepay  detailed  out-year  Program  Objectives  Memorandum  (POM) 
estimates 

•  Substantiate  implementation  of  a  wide-area  distributed  logistics  network. 

The  cost-benefit  and  economic  impact  analyses  should  assume  that  variable- 
length  DLSS  formatted  transactions  will  be  implemented  along  with  the  LGN 
architecture.  Thus,  the  analyses  should  consider  all  MODELS  recommendations. 


The  cost-benefit  analysis  should  identify  and  quantify  all  life-cycle  costs  and 
benefits.  It  should  be  performed  on  an  incremental  basis  in  which  the  costs  and 
benefits  are  compared  with  the  comparable  costs  and  benefits  of  the  existing  DAAS 
logistics  information  communications  system  (after  completion  of  the  current 
DARP). 

The  benefits  to  be  evaluated  should  include  communications  cost  savings, 
improvements  in  logistics  system  effectiveness  through  the  availability  of  more 
timely  and  comprehensive  information,  and  improvements  in  functional  operations 
effectiveness.  These  benefits  must  also  include  forecasts  of  the  impact  of  future 
expansion  and  enhancements  (such  as  transmission  of  graphics  data,  weapons 
system  management,  crisis  management  planning  and  execution,  and  EDI  with  the 
commercial  sector)  on  the  existing  and  proposed  systems. 

3.3.6  Full  Implementation  Planning 

The  third  step  in  the  LGN  implementation  process  is  the  full  implementation 
planning.  The  MODELS  FYP  is  a  preliminary  plan.  Detailed  plans  for  execution 
should  be  made  after  the  prototype  test  has  supported  the  technical  feasibility  and 
practicality  of  the  LGN,  and  the  cost-benefit  and  economic  impacts  analysis 
indicates  it  is  economically  viable.  This  is  not  to  say  that  preliminary  transition 
plans,  already  being  considered,  should  not  be  drafted  prior  to  and  during  the  test. 
These  are  necessary  for  resource  allocation  forecasting  and  to  ensure  that  the 
MODELS  program  is  included  in  POM  considerations  by  the  Services  and  Agencies 
in  their  outyear  budgeting  processes. 

The  full  implementation  plan  must  address  implementation  of  the  revised 
DLSS  procedures;  associated  variable-length  transactions;  and  the  LGN  hardware, 
software,  and  communications.  Each  of  these  components  has  major  issues. 

A  primary  issue  in  the  DLSS  procedures  and  transactions  implementation 
planning  is  the  schedule  for  transition  to  the  new  transactions.  One  alternative  is  to 
wait  until  LGNs  are  installed  at  all  major  logistics  sites  and  the  network  is  tested. 
The  disadvantage  of  that  approach  is  that  it  will  probably  take  close  to  a  decade  to 
complete  all  of  the  necessary  approvals,  procurements,  installations,  and  testing. 
Another  alternative  is  to  develop  and  implement  all  the  features  and  capabilities  of 
the  LGN  concept  at  the  two  DAAS  sites,  thereby  facilitating  conversion  to  the 


modernized  procedures  and  variable-length  transactions  before  1990,  and  then 
implement  the  remaining  LGNs. 

Issues  associated  with  the  LGN  include  identifying  who  will  own,  control,  and 
staff  the  LGN  sites,  which  will  probably  be  collocated  and  housed  in  Service  and 
DLA  facilities.  If  DLSSO  owns  and  operates  the  equipment,  should  it  rent  space  and 
back-up  operators  from  the  local  site  organization?  If  the  Services  and  DLA  own  the 
LGNs  at  their  respective  sites,  does  DLSSO  lose  the  flexibility  of  being  able  to  make 
rapid  changes  and  updates?  Also,  who  is  responsible  for  maintenance  and  repair  of 
hardware  in  either  situation? 

The  MODELS  Implementation  Plan  must  also  address  phased  implementation 
issues  (e.g.,  should  implementation  be  performed  by  the  Service  and  Agency  or  by 
logistics  organizational  level);  test  plans  (who  prepares  them,  conducts  them, 
approves  satisfactory  completion  of  testing);  transition  schedules  (what  is  the  order 
of  conversion  to  modernized  DLSS  formats  since  it  is  impractical  to  expect  a 
conversion  to  all  new  transactions  on  a  single  designated  day);  and  operations  and 
maintenance  plans  (does  the  Government  form  operations  troubleshooting  and 
maintenance  teams  that  handle  problems  on  site  or  should  that  service  obtained 
under  contract  as  part  of  the  hardware  and  software  procurements). 

These  and  many  similar  issues  must  be  formulated  and  resolved  in  the  full 
implementation  planning. 

3.3.7  Request  for  Proposal  Preparation  and  Competitive  Procurement 

At  the  conclusion  of  the  previously  described  tasks,  there  will  be  an  assessment 
of  the  feasibility  and  practicality  of  the  new  DLSS  formats  and  the  LGN  accom 
panied  by  a  plan  to  ensure  effective  implementation  of  the  modifications  on  a  DoD- 
wide  basis.  A  final  version  of  the  functional  description  will  define  the  required 
DLSS  changes,  identify  sites  at  which  the  LGNs  are  to  be  installed,  describe  the 
connection  of  satellite  facilities  to  these  sites,  and  identify  the  variations  required  in 
LGN  functions  to  meet  the  requirements  of  specific  user  configurations.  The 
DDBMS  or  DBMS  network  software,  directories,  and  dictionaries  required  to 
support  the  logistics  network  operation  will  also  have  been  specified.  Finally,  many, 
if  not  most,  of  the  issues  similar  to  those  described  above  will  have  been  addressed 
and  resolved. 


The  functional  description  and  implementation  plan  will  provide  the  basis  for  a 
competitive  RFP  defining  hardware  and  software  requirements,  test  and  acceptance 
plans,  and  schedules  and  milestones  to  implement  the  MODELS  recommendations. 
In  addition  to  the  formal  RFP.  required  supplemental  documentation  must  also  be 
prepared  to  support  the  procurement  activities.  These  documents  include  a  Project 
Plan,  Outside  Sources  Considerations,  supporting  studies,  a  Systems  Analysis  and 
Requirements  Document  (SARD),  a  market  survey,  procurement  justifications,  and 
a  Systems  Authorization  Document  (SAD).  Finally,  all  of  this  documentation  and 
the  implementation  plans  and  funding  requirements  must  be  presented  and 
approved  in  the  MAISRC  process. 

When  approvals  are  received  and  documentation  is  in  place,  the  actual 
procurement  process  can  be  started.  This  process  will  include  technical  and  cost 
evaluations  of  all  proposals  received,  tests  of  proposed  hardware  and  software,  award 
of  one  or  more  contracts,  and  acceptance  testing  of  the  proposed  equipment  and 
software.  Only  then  can  the  implementation  process  truly  begin. 

3.4  RESOURCE  REQUIREMENTS 

Tables  3-1  and  3-2  present  summary  estimates  of  resource  requirements  for  the 
MODELS  program  activities  described  in  the  Implementation  Plan  and  depicted  in 
Figure  3-1.  These  estimates  identify  resources  for  each  of  the  organizations  partici¬ 
pating  in  this  program  by  project  and  by  fiscal  year. 

OSD  participation  will  consist  primarily  of  policy  formulation,  regular  ongoing 
reviews  of  program  activities  and  progress,  and  decisions  on  major  modernization 
issues. 

DLSSO  participation  will  include  detailed  reviews  of  program  activities;  day- 
to-day  program  management  -  budgeting,  issue  formulation,  FYP  updates,  and 
related  activities;  and  participation  in  technical  direction  of  the  program.  Technical 
participation  will  include  extensive  involvement  in  the  review  of  the  LOGDESMAP 
data  base  and  design  of  the  new  DLSS  data  dictionary  and  associated  directories.  It 
will  also  include  active  participation  in  the  design  and  definition  of  variable-length 
transactions  and  DLSS  procedures  modifications. 

DAASO  will  participate  in  the  design  and  definition  of  the  variable-length 
transactions,  including  development  of  automated  data  flow  diagrams  and  the  DLSS 
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data  dictionary.  However,  it  is  anticipated  that  their  most  extensive  involvement 
will  be  in  the  specification,  design,  and  development  of  the  LGX  data  base  applica¬ 
tions  software. 

The  Services,  DLA,  Defense  Transportation  Agencies,  OJCS/Joint  Deployment 
Agency  (JDA),  and  other  interested  or  affected  organizations  should  all  participate 
in  an  active  review  and  coordination  capacity.  They  will  review  policy  and  the  LGX 
data  base  design,  as  well  as  support  site  installations. 


APPENDIX  A 


GLOSSARY 


The  following  is  a  list  of  acronyms  and  their  definitions  used  in  this  report. 


ACO 

ADP 

ADPE 

A&L 

ANSI 

AUTODIN 


CALS 

CAO 

CDR 

CINC 

COBOL 

COMM  RI 

CONUS 

COOP 


DAAS 

DAASO 

DAASO-BFS 


DAISY 


DARP 

DBA 

DBMS 

DCASR 

DDBMS 


Administrative  Contracting  Officer 
Automatic  Data  Processing 
Automatic  Data  Processing  Equipment 
Acquisition  and  Logistics 
American  National  Standards  Institute 
Automatic  Digital  Network 

Computer-Aided  Logistics  Support 
Contract  Administrative  Office 
Contract  Deficiency  Report 
Commander-in-Chief 
Common  Business  Oriented  Language 
Communications  Routing  Identifier 
Continental  United  States 
Continuity  of  Operations  Plan 

Defense  Automatic  Addressing  System 

Defense  Automatic  Addressing  System  Office 

Defense  Automatic  Addressing  System  Office  Baseline 
Functional  Specification 

Defense  Reutilization  and  Marketing  Service  Automated 
Information  System 

DAAS  ADPE  Replacement  Program 

Data  Base  Administrator 

Data  Base  Management  System 

Defense  Contract  Administration  Service  Region 

Distributed  Data  Base  Management  System 
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DD/D 

DD/DS 

DDN 

DEPRA 

DIDS 

DLA 

DLANET 

DLSC 

DLSS 

DLSSO 

DoD 

DoDAAC 

DoDAAD 

DoDAAF 

DoDI 

DoD  RI 

DRMO 

DRMS 

DTS 

EDI 

FAD 

FIPS 

FMS 

FSC 

FYP 

Gbytes 

GFE 

GP 

GSA 


Data  Dictionary/Directory 

Data  Dietionary'Directory  Subsystem 

Defense  Data  Network 

Defense  European  and  Pacific  Redistribution  Activity 
Defense  Integrated  Data  System 
Defense  Logistics  Agency 

Defense  Logistics  Agency  Telecommunications  Network 
Defense  Logistics  Service  Center 
Defense  Logistics  Standard  Systems 
Defense  Logistics  Standard  Systems  Office 
Department  of  Defense 

Department  of  Defense  Activity  Address  Code 
Department  of  Defense  Activity  Address  Directory 
Department  of  Defense  Activity  Address  File 
Department  of  Defense  Instruction 
Department  of  Defense  Routing  Identifier 
Defense  Reutilization  and  Marketing  Office 
Defense  Reutilization  and  Marketing  Service 
Defense  Transportation  System 

Electronic  Data  Interchange 

Force  Activity  Designator 

Federal  Information  Processing  Standard 

Foreign  Military  Sales 

Federal  Supply  Class 

Five-Year  Plan 

Gigabytes 

Government-Furnished  Equipment 

Gateway  Processor 

General  Services  Administration 


ICP 


Inventory  Control  Point 


ILCO 

International  Logistics  Control  Offices 

ILCS 

International  Logistics  Communications  System 

IM 

Inventory  Manager 

IMM 

Integrated  Material  Manager 

IMP 

Interface  Message  Processor 

I/O 

Input/Output 

IRDS 

Information  Resource  Dictionary  System 

I-S/A  AMPE 

Inter-Service/Agency  Automated  Message  Processing 
Exchange 

ISO 

International  Standards  Organization 

JCS 

Joint  Chiefs  of  Staff 

JDA 

Joint  Deployment  Agency 

JDS 

Joint  Deployment  System 

JOPES 

Joint  Operations,  Planning,  and  Execution  System 

Kbytes 

Kilobytes 

LGN 

Logistics  Gateway  Node 

LIDS 

Logistics  Information  Data  Service 

LOGDESD 

Logistics  Data  Element  Standard  Dictionary 

LOGDESMAP 

Logistics  Data  Element  Standardization  and  Management 
Program 

LOGDRMS 

Logistics  Data  Resource  Management  System 

MAC 

MAISRC 

MAPAF 

Mbyte 

MCDN 

MILRI 

MILSCAP 

MILSPETS 

MILSTAMP 


Military  Airlift  Command 

Major  Automated  Information  System  Review  Council 
Military  Assistance  Program  Address  File 
Megabyte 

Marine  Corps  Data  Network 
Military  Routing  Identifier 

Military  Standard  Contract  Administration  Procedures 
Military  Standard  Petroleum  System 

Military  Standard  Transportation  and  Movement  Procedures 


MILSTEP  Military  Supply  and  Transportation  Evaluation  Procedures 

MILSTRAP  Military  Standard  Transaction  Reporting  and  Accounting 
Procedures 

MILSTRIP  Military  Standard  Requisitioning  and  Issue  Procedures 
MODELS  Modernization  of  Defense  Logistics  Standard  Systems 

MRO  Materiel  Release  Order 

MSC  Military  Sealift  Command 

MTMC  Military  Traffic  Management  Command 

NBS  National  Bureau  of  Standards 

NDBMS  Network  Data  Base  Management  System 

NICP  National  Inventory  Control  Point 

NSN  National  Stock  Number 

OASD(A&L)  Office  of  the  Assistant  Secretary  of  Defense  (Acquisition  and 
Logistics) 

OCONUS  Outside  the  Continental  United  States 

OJCS  Organization  of  the  Joint  Chiefs  of  Staff 

OSD  Office  of  the  Secretary  of  Defense 

OSI  Open  Systems  Interconnection 

PCO  Procurement  Contracting  Office 

PIN  Part  Identification  Number 

PLAD  Plain  Language  Address  Designator 

P/N  Part  Number 

PO  Procurement  Office 

POM  Program  Objectives  Memorandum 

QDR  Quality  Deficiency  Report 

R&D  Research  and  Development 

R&M  Reutilization  and  Marketing 

RDD  Required  Delivery  Date 

REPSHIPS  Reports  of  Shipment 
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ROD 


Request  for  Proposal 
Report  of  Discrepancy 


SAD 

SARD 

SOS 

SPLICE 


Service/Agency 

Systems  Authorization  Document 

Systems  Analysis  and  Requirements  Document 

Source  of  Supply 

Stock  Point  Logistics  Integrated  Communications 
Environment 


TDCC 


Transportation  Data  Coordinating  Committee 


UMMIPS 


Uniform  Materiel  Movement  and  Issue  Priority  System 


WBS  Work  Breakdown  Structure 

WIS  WWMCCS  Information  System 

WSM  Weapons  System  Manager 

WWMCCS  Worldwide  Military  Command  and  Control  System 
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APPENDIX  B 

PRIORITIES  FOR  MODELS  IMPLEMENTATION 


The  Modernization  of  DE/ense  Logistics  Standard  Systems  (MODELS) 
functional  and  technology-related  requirements1  presented  in  this  appendix  are 
organized  by  implementation  priority.  The  priorities  are  organized  in 
six  classification  categories  in  Table  B- 1. 

PROJECT  1-F  REQUIREMENTS 

The  first  priority  set  of  requirements2  are  for  transformation  of  current 
Defense  Logistics  Standard  Systems  (DLSS)  80-column  transactions  and  procedures 
to  Electronic  Data  Interchange  (EDI)-concept  variable-length  transactions,  with 
changes  in  procedures,  as  required. 

•  The  MODELS  conceptual  design  must  provide  flexible  transaction  formats 
and  a  methodology  for  expedited  adoption  of  new  codes  and  procedures  as 
logistics  operations  and  management  information  needs  change. 

•  Uniform  Materiel  Movement  and  Issue  Priority  System  (UMMIPS)  per¬ 
formance  measurement  standards  and  procedures  should  become  part  of  the 
restructured,  expanded  DLSS,  and  must  continue  close  coordination  with 
the  Joint  Chiefs  of  Staff  (JCS)  for  Force  Activity  Designator  (FAD)  and 
priority  assignments. 

•  The  MODELS  concept  must  provide  the  capability  for  internal  Service 
Agency  (S/A)  unique  data  needs  to  be  accommodated  in  DLSS  inter-S/A 
transactions. 

•  MODELS  transaction  formats  must  provide  flexibility  to  handle  two-party 
and  multi-party  informational  exchanges,  even  though  not  formally  part  of 
DLSS  procedures. 


1  L.Ml  Report  I)I,502R1  "Functional  Requirements"  summary  from  De/'en.se  /.otfis/ti  .v 
Standard  Systems  Functmnnl  l{>'<iiurrnwnts  Yuumj.  I’aul  A  Mar  1987 
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1 ;  1 


.  /.  .-  -r,  /  v  -C,  C-  -T,. -  .  ",  r  - 


s  y 


Classification 


Description 


1- F  Project  1-F:  Transformation  of  current  DLSS,  80-column  transactions  and 

(1986  -  1988)  procedures  to  EDI-concept  variable-length  transactions,  with  changes  m 

procedures,  as  required 

2- F  Project  2-F:  The  expansion  of  current  DLSS  to  accommodate  increased  scope 

(1988  -  1991)  of  coverage  [e  g.,  Military  Standard  Contract  Administration  Procedures 

(MILSCAP)  to  include  secondary  item  acquisition  activities,  Military  Suoply 
and  Transportation  Evaluation  Procedures  (MILSTEP)  to  include  a  broad 
range  of  logistics  management  and  operations  performance  measures];  the 
incorporation  of  commodity  specific  procedures  into  the  standard  DLSS  [e  g  , 
Military  Standard  Petroleum  System  (MILSPETS)  integrated  into  Military 
Standard  Requisitioning  and  issue  Procedures  (MILSTRIP),  Military  Standard 
Transaction  Reporting  and  Accounting  Procedures  (MILSTRAP),  etc  ],  and 
the  interfacing  of  external  defense  standard  systems  into  the  DLSS  network 
of  systems 

Project  3-F :  Interfacing  existing  and  developing  defense  standard  systems 
(i  e.,  systems  to  support  operations  or  management  information  across  the 
Department  and  which  require  inter-S/A  exchange  of  information)  into  the 
DLSS  network  of  systems  and  procedures. 

F  =  Designation  for  Functional  modernization  projects,  to  change  and  enhance 

functional  capabilities  of  DLSS  procedures. 

1-S  Project  1-S:  Prototype  testing  of  the  logistics  gateway  node  (LGN)  and 

(1986  -  1989)  logistics  network  concepts  to  assess  feasibility  and  better  define  cost-benefit 

relationships 

Project  2-S:  imolement  the  LGN  and  logistics  network  at  100  major  sites  and 
implementation  of  Projects  1-F  and  2-F  transactions  throughout  the  defense 
logistics  community  Includes  limited  interactive  inquiry  capability  and  ad 
hoc  reporting 

Project  3-S.  Enhancement  of  the  logistics  network  to  fully  interface  all 
defense  standard  systems  operating  within  the  Department,  including 
policies  and  procedures  external  to  the  DLSS,  but  requiring  mter-S/A 
information  exchange  and  interaction  with  the  commercial  sector  for  a  full 
range  of  electronic  communications  incorporation  of  3-F  transactions 

S  -  Designation  for  System  modernization  projects,  enhancing  automatic  data 

processing  (ADP)  and  telecommunications  capabilities  for  DLSS  operations 


2-S 

(1992  -  Later) 


3-S 

( 1 994  -  Later) 


3-F 

(1991  -  Later) 


•  The  MODELS  concept  design  should  make  it  easy  to  measure  the 
performance  of  a  range  of  operations  and  trend  indicators  at  the  wholesale 
operations  level. 

•  The  MODELS  concept  should  identify  methods  and  procedures  to  collect 
pipeline  performance  measurement  data  at  each  segment  of  the  process,  as 
it  occurs.  The  DLSS  should  standardize  the  definition  of  each  pipeline 
segment. 

•  MODELS  acquisition  function  transaction  formats  must  be  variable  in 
length  to  accommodate  all  S/A  contract  data  exchange  requirements. 

•  DLSS  procedures  should  standardize  the  requisitioning  transaction  to 
accommodate  retail-level  end  user  requirements. 

•  History  retention  periods,  for  each  type  of  transaction,  should  be 
standardized.  Visibility  of  referrals,  backorders,  depot  denials,  and  cancel¬ 
lations  should  be  enhanced. 

•  The  use  of  priority  codes,  project  codes,  and  weapons  system  codes  in  the 
requisition  transaction  must  be  defined  and  accommodated  in  the  MODELS 
concept. 

•  MODELS  must  establish  standards  for  methods  of  supply  determination 
processes  to  assure  responsive  support  of  user  requirements. 

•  MODELS  must  incorporate  improved  interface  capabilities  to  permit  timely 
processing  of  modifications  and  cancellations. 

•  Modernized  DLSS  should  integrate  DoD  Manual  4140. 27-M  for  shelf-life 
items  and  hazardous  materiel  procedures  into  an  expanded  wholesale 
storage  standard. 

•  The  MODELS  concept  must  include  automating  processes  to  accommodate 
and  improve  the  productivity  of  conducting  physical  inventory  procedures. 

•  The  expanded-DLSS  procedures  must  provide  for  the  identification, 
definition,  control,  and  dissemination  of  data  standards.  This  role  should 
include  the  development  of  the  data  dictionary  and  related  directories. 

•  DLSS  transaction  formats  should  be  variable-length  records  and  should 
conform  to  an  electronic  data  exchange  standard.  Serious  consideration 
should  be  given  to  using  EDI  standards  to  establish  compatibility  with  the 
commercial  sector.  Therefore,  DLSS  transaction  formats  should  be 
formulated  and  established  in  cooperation  with  the  American  National 
Standards  Institute  (ANSI)  EDI  Committee,  associated  subcommittees  such 
as  the  Transportation  Data  Coordinating  Committee  (TDCC),  and  industry 
representatives. 


•  The  MODELS  concept  should  provide  for  modernized  DLSS  procedures  and 
transaction  data  elements  to  accommodate  implementation,  through 
UMMIPS,  of  separate  issue  and  transportation  priority  coding  systems. 

•  Individual  S/A  logistics  systems  need  to  be  designed  with  the  total  DoD 
logistics  community  in  mind.  An  overall  DoD  logistics  system  moderni¬ 
zation  plan  should  be  formally  prepared  and  regularly  updated,  as  part  of 
the  MODELS  continuing  modernization  process. 

PROJECT  2-F  REQUIREMENTS 

The  second  priority  set  of  requirements  are  for  the  expansion  of  current  DLSS 
to  increase  its  scope  of  coverage  [e.g..  Military  Standard  Contract  Administration 
Procedures  (MILSCAP)  to  include  secondary  item  acquisition  activities.  Military 
Supply  and  Transportation  Evaluation  Procedures  (MILSTEP)  to  include  a  broad 
range  of  logistics  management  and  operations  performance  measures];  the 
integration  of  commodity  specific  procedures  within  the  standard  DLSS  [e.g.. 
Military  Standard  Petroleum  System  (MILSPETS)  integrated  into  Military 
Standard  Requisitioning  and  Issue  Procedures  (MILSTRIP),  Military  Standard 
Transaction  Reporting  and  Accounting  Procedures  (MILSTRAP),  etc.];  and  the 
interface  of  external  defense  standard  systems  with  the  DLSS  network  of  systems 
[e.g.,  Defense  Integrated  Data  System  (DIDS),  Weapons  System  Manager  (WSM), 
Defense  Reutilization  and  Marketing  Service  (DRMS)  Automated  Information 
System  (DAISY)].  These  requirements  are  all  closely  associated  with  the  current 
DLSS  and  can  be  thought  of  as  an  extension  of  the  current  DLSS.  These 
requirements  will  require  some  policy  decisions  prior  to  development  of  Project  2-F 
implementation  plans.  However,  the  policy  decisions  are  not  as  broad  in  scope  as 
those  required  prior  to  implementation  of  Project  3-F.  The  following  are  Project  2-F 
MODELS  requirements:^ 

•  The  MODELS  concept  design  should  make  it  easy  to  measure  the 
performance  of  a  range  of  operations  and  trend  indicators  at  the  wholesale 
operations  level. 

•  The  MODELS  concept  must  have  the  capability  to  electronically  collect, 
collate,  and  summarize  discrepancy  reports  from  all  S/A  organizations 
worldwide  as  one  element  of  performance  measurement  reporting.  These 
discrepancy  reporting  evaluation  procedures  should  be  incorporated  into 
DoD-wide  standard  performance  measures. 


■*Order  of  requirements  does  not  indicate  any  priority  within  project  2-F 


•  Standard  criteria  for  measuring  procurement  and  contracting  performance 
should  be  developed.  The  MODELS  concept  must  include  procedures  for 
regular  collection  of  these  standardized  performance  measurement  data  as 
a  normal  process. 

•  Modernized  DLSS  procedures  must  define  a  standard  weapons-system 
performance  measurement  program,  including  standardized  weapons 
system  identification  codes.  The  DLSS  procedures  must  allow  for  multiple 
weapons  system  coding  for  common-use  items. 

•  A  comprehensive  set  of  logistics  operations  performance  measurements 
should  be  developed  and  implemented  through  a  DLSS  procedural  publica¬ 
tion. 

•  The  modernized  DLSS  procedures  should  encompass  standard  procurement 
functions  and  related  inter-S/A  information  exchange  requirements. 

•  MODELS  formats  for  acquisition  transactions  must  be  variable  in  length  to 
accommodate  all  S/A  contract  data  exchange  requirements. 

•  Contract  Deficiency  Reports  (CDRs)  should  become  a  part  of  Administrative 
Contracting  Officer/Procurement  Contracting  Officer  data  bases  and  should 
be  available  on-line. 

•  The  MODELS  concept  should  automate  response  and  disposition  instruc¬ 
tion  processing,  in  accordance  with  published  standards. 

•  The  modernized,  expanded  DLSS  should  standardize  processing  of  materiel 
and  equipment  to  Defense  Reutilization  and  Marketing  Offices  (DRMOs), 
including  all  types  of  local  turn-ins.  The  automated  processing  of  materiel 
to  reutilizacion  and  marketing  (R&M)  functions,  even  for  local  turn-ins, 
should  be  coordinated  with  MODELS  implementation. 

•  Procedures  for  all  shipment  preparation  and  documentation  should  be 
incorporated  into  the  modernized  DLSS. 

•  The  MODELS  concept  should  review  DIDS  modernization  requirements 
and  plans  and  closely  coordinate  the  MODELS  conceptual  design  to 
accommodate  future  DIDS  capabilities. 

•  All  inventory  management  and  control  issues  and  procedures  should  be 
integrated  in  an  expanded  DLSS. 

•  Distribution  and  redistribution  procedures  should  be  consolidated  under 
one  expanded  DLSS  procedure  for  wholesale  supply  management. 

•  The  use  of  priority  codes,  project  codes,  and  weapons  system  codes  in  the 
requisition  transaction  must  be  defined  and  accommodated  in  the  MODELS 
concept. 
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The  MODELS  concept  should  include  a  method  of  providing  denial  status 
directly  to  requisitioners,  either  at  a  retail-supply  point  or  bv  end  users 
through  the  retail-supply  point  system.  Standardized  procedures  and 
timeframes  are  needed  to  improve  data  records  and  delivery  and  receipt 
records  for  billing  purposes  throughout  all  levels  of  the  logistics  community. 


•  With  a  network-wide  interactive  inquiry  capability  there  may  no  longer  be 
a  need  for  pushed  follow-ups  to  update  centralized  data  bases.  This  change 
would  require  that  standardized  procedures  and  guidelines  be  developed  for 
inquiry  capability. 


•  Modernized  DLSS  must  include  procedures  and  standard  rules  concerning 
the  stages  when  changes  can  be  made  (during  which  segments  of  the 
pipeline  process),  what  changes  are  authorized  with  various  modes  of  data 
access  (interactive  versus  transactional),  and  who  is  authorized  to  initiate 
interactive  changes,  with  appropriate  precautions  regarding  access  and 
record- level  security. 


•  DLSS  guidelines  and  procedures  need  to  be  developed  and  implemented  for 
processing  backorder  releases.  A  priority  processing  scheme,  similar  to  that 
used  for  in-process  requisitions,  should  be  applied  to  backorder  release 
processing.  Partial  shipments  of  priority  materiel  should  be  considered  and 
rules  and  automated  procedures  developed  to  standardize  when  such 
shipments  can  be  authorized  and  by  whom. 


•  Procedures  need  improvement  in  Inventory  Control  Point  (ICP)  determina¬ 
tion  and  processing  of  wholesale  excess  materiel. 


One  procedural  document  should  define  a  standard  set  of  reporting 
procedures  for  all  types  of  discrepancies.  Methods  for  automated 
integration  of  deficiency  reporting  procedures  through  data  base  techniques 
and  on-line,  interactive  information  retrieval  capabilities  should  be 
considered. 


Shipment  preparation  procedures  should  all  be  integrated  in  modernized 
DLSS.  The  MODELS  concept  must  be  able  to  accommodate  the  full  extent 
of  information  exchange  requirements.  The  MODELS  concept  must  also 
allow  for  and  encourage  the  use  of  bar-coding  and  EDI  standards  for 
improved  documentation  and  processing  efficiency. 


The  MODELS  concept  must  provide  for  exchange  of  transportation 
information/data  with  all  logistics  community  activities  and  also  some 
activities  that  are  not  included  in  the  defense  logistics  operations- 
management  environment,  particularly  JCS,  the  Joint  Deployment  Agency 
(JDA),  and  the  Commanders-in-Chief(CINCs). 


•  The  MODELS  concept  must  provide  for  a  reduction  of  paperwork.  It  must 
improve  the  flow  of  compatible  data,  on  a  near-real-time  basis  in  some 
cases,  within  the  defense  community  and  to  and  from  other  organizations. 
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including  commercial  carriers.  Electronic  data  exchange  concepts  and 
standards  must  be  incorporated. 

•  The  DLSS-expanded  functions  must  provide  for  evaluation  and  develop¬ 
ment  of  procedures  and  data  exchange  requirements  in  theaters  of 
operation,  compatible  with  the  the  Defense  Transportation  System  (DTS't 
and  CONUS-based  activities  that  provide  transportation  data  to  the  theater 
or  require  data  from  the  theater. 

•  The  MODELS  concept  must  provide  for  exchange  of  data  concerning 
transportation  authorization  decision  process  and  the  traffic  management 
function. 

•  The  MODELS  concept  must  provide  for  an  appropriate  level  of  recording 
and  reporting  of  transportation  movement  information  and  data. 

•  Modernized  DLSS  procedures  and  the  MODELS  information  exchange 
technology  concepts  must  provide  standardized  interfaces  to  unique 
commodity  systems  (e.g.,  ammunition,  petroleum).  Eventually  such  unique 
Service-to-Service  and  Service-to-Defense  Logistics  Agency  (DLA)  proce¬ 
dures  and  automated  systems  must  be  fully  interfaced  with  the  MODELS 
concept. 

•  The  MODELS  concept  should  provide  for  a  working  interface  between  Joint 
operations  systems  and  the  DLSS. 

•  Modernized  DLSS  must  establish  procedures  and  standards  for  DoD-wide 
logistics  information  inquiry. 

PROJECT  3-F  REQUIREMENTS 

The  third  priority  set  of  functional  requirements  are  to  interface  existing  and 
developing  defense  standard  systems  (i.e.,  systems  to  support  operations  or 
management  information  across  the  Department  and  which  require  inter-S  A 
exchange  of  information)  with  the  DLSS  network  of  systems  and  procedures  [e.g.. 
maintenance,  requirements  analysis,  Computer-Aided  Logistics  Support  (CALS) 
data].  The  following  requirements4  are  currently  not  closely  associated  with  the 
DLSS  and  will  require  important  policy  decisions  prior  to  the  development  of 
Project  3-F  implementation  plans: 

•  Informational  inputs  and  function-to-function  interfaces  (for  example, 
supply-to-transportation)  should  be  reevaluated  and  redefined  to  overcome 
known  inter-S/A  information  deficiencies  not  addressed  by  the  current 
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DLSS  and  to  meet  the  needs  of  new  and  expanding  functional  and  manage 
ment  information  requirements. 

•  Modernized  DLSS  must  provide  for  standardization  of  retail  procedures. 

•  The  MODELS  concept  must  coordinate  with  all  S/ A  logistics  modernization 
requirements. 

•  The  MODELS  conceptual  design  should  accommodate  all  information 
exchanges  between  logistics  functions  and  operational/management  compo¬ 
nents. 

•  The  MODELS  concept  should  include  methods  for  collecting  and  reporting 
data  at  the  retail  operations  level  to  satisfy  a  variety  of  performance  meas¬ 
urement  criteria. 

•  The  MODELS  design  must  provide  the  automated  capabilities  to  perform 
weapons  system-oriented  performance  measurement  of  logistics  operations. 
This  must  include  access  to  wholesale  and  retail  operational  performance 
measurement  data  classified  by  weapons  system. 

•  The  MODELS  effort  should  continue  to  closely  monitor  CALS  developments 
and  information  exchange  protocols  and  procedures.  As  standards  are 
developed  by  the  OSD-CALS  Group  for  technical  data  acquisition  and 
distribution  procedures  and  communications  interfaces,  these  standards 
should  be  published  as  part  of  the  modernized  DLSS  technical  data 
functions. 

•  Retail  requisitioning  should  be  DLSS  compatible  throughout  the  S/A 
logistics  community. 

•  The  expanded  DLSS  must  develop  DoD  standards  for  analysis  of  demand. 
They  must  also  present  requirements  data  including  initial  provisioning 
procedures  and  the  control  and  management  of  war  reserve  materiel 
requirements. 

•  The  MODELS  concept  must  provide  an  automated  information  interface  for 
maintenance  requirements.  The  modernized  DLSS  must  provide  for  the 
induction  and  return  of  reparables,  so  that  the  Integrated  Material 
Manager  (IMM)Tnventory  Manager  (IM)  (owning)  has  the  necessary  asset 
visibility  to  allow  for  proper  control,  and  to  take  asset  status  into 
consideration  when  performing  procurements  and  redistributions. 

•  MODELS  must  improve  IM  visibility  of  retail  excess  materiel.  Also,  the 
DLSS  should  identify  procedures  to  integrate  retail  returns  with  discrep¬ 
ancy  processing  systems. 

•  DLSS  procedures  need  to  be  developed  to  define  standards  for  the  use  and 
transmission  of  technical  data.  The  MODELS  design  must  allow  and 
promote  on-line  access  to  catalog  and  technical  data,  with  full  graphics 


capability  for  transmission  and  display  of  digitized  images.  This  capability 
must  incorporate  CALS-developed  orocedure  and  protocol  standards. 

•  The  MODELS  concept  should  provide  for  standardization  of  procedures  for 
the  exchange  of  technical  data  between  the  S/As. 

•  The  DLSS  must  provide  for  standardization  of  cataloging  activities  related 
to  technical  data,  engineering  drawings,  and  documents  in  accordance  with 
the  OSD-CALS  Group  recommendations. 

•  The  DLSS  should  incorporate  the  findings  and  recommendations  of  the 
CALS  project  for  technical  data  storage  and  retrieval  standardized  proce¬ 
dures. 

•  Wholesale  receipt  procedures  for  information  access  and  exchange  between 
the  depot  and  ICP  should  be  fully  covered  under  the  modernized  DLSS, 
including  use  of  bar-coding  technology,  interface  requirements  to  other 
logistics  functions,  and  performance  measurement/quality  control  pro¬ 
cesses. 

•  The  MODELS  concept  must  recognize  the  integral  role  of  R&M  in  the  total 
logistics  process  and  should  incorporate  an  evolving  DAISY  capability  for 
on-line  visibility  of  excess  assets.  Asset  visibility  should  be  available  to 
wholesale  IMs  and  all  retail-level  supply  echelons.  OSD  should  consider  the 
integration  of  R&M  functional  procedures  into  the  DLSS  scope  of 
responsibility. 

PROJECT  1-S  REQUIREMENTS 

The  following  are  requirements-^  for  prototype  testing  of  the  LGN  and  logistics 
network  concepts  to  assess  feasibility  and  better  define  cost-benefit  relationships: 

•  MODELS  will  require  some  degree  of  data  base  and  data  model  standard¬ 
ization. 

•  A  standard  DoD  logistics  data  elements  dictionary  will  be  a  requisite  ( and  a 
responsibility  of  the  DLSS),  to  include  all  data  elements,  terms,  and 
definitions  used  in  S'A  logistics  system  interfaces  and  information 
exchanges. 

•  The  expanded-DLSS  procedures  must  provide  for  the  identification, 
definition,  control,  and  dissemination  of  data  standards.  This  role  should 
include  the  development  of  data  dictionaries. 

•  The  MODELS  concept  must  provide  for  an  electronic  mail  capability. 
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•  The  MODELS  concept  must  provide  for  continued  use  of  batch  processing 
and  the  standardized  exchange  of  data  in  batches. 

•  DLSS  modernization  should  carefully  review  existing  and  developing 
communications  standards  for  the  Open  Systems  Interconnection  (OSD 
seven-layer  reference  model,  to  facilitate  inter-operability  in  the  logistics 
community  among  heterogeneous  data  networks  The  Defense  Logistics 
Standard  Systems  Office  (DLSSO)  must  take  an  active  role  in  ensuring 
adherence  to  DoD-wide  logistics  applications  data  management  standards. 

•  The  MODELS  concept  recognizes  the  use  of  modern  data  base  management 
system  (DBMS)  technology  by  the  S/As  and  must  provide  for  procedures  to 
standardize  data  element  definitions  in  the  S/As.  In  the  interim,  data 
dictionaries  should  be  established  to  facilitate  data  element  translations 
among  S.  As. 

•  The  MODELS  concept  must  be  structured  to  take  advantage  of  the 
emerging  distributed  data  base  management  system  (DDBMS)  technology. 
Existing  DDBMS  technology  should  be  reviewed  to  determine  its  ability  to 
address  the  needs  of  the  logistics  community. 

•  The  MODELS  concept  must  provide  for  electronic  exchange  of  large  text- 
fields  of  contract-related  information. 

•  Individual  S/A  logistics  systems  need  to  be  designed  with  the  total  DoD 
logistics  community  in  mind.  An  overall  DoD  logistics  systems  modern¬ 
ization  plan  should  be  formally  prepared  and  regularly  updated,  as  part  of 
the  MODELS  continuing  modernization  process. 

PROJECT  2-S  REQUIREMENTS 

To  implement  the  LGN  architecture  at  major  sites  and  to  integrate  Project  1  F 
and  2-F  transactions  throughout  the  defense  logistics  community  requires  the 
following:^ 

•  The  MODELS  concept  must  coordinate  with  all  S/A  logistics  modernization 
requirements.  It  must  also  be  able  to  satisfy  logistics  information  require¬ 
ments  and  fully  support  resupply  requirements  in  crisis  or  wartime  situ 
ations. 

•  The  MODELS  concept  should  include  the  capability  to:  (1)  accumulate 
performance  characteristic  data  generated  as  a  normal  process  of  daily 
operations,  and  (2)  provide  for  the  retrieval  of  performance  data  in  a  form 
that  the  intended  recipient  will  find  most  useful.  This  capability  should 
include  collection  of  data,  based  on  normally-generated  operations  data  ( not 
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special  data  collection  efforts),  and  rapid  retrieval  in  easily  modified 
formats  to  view  information  from  different  points  of  interest. 

•  The  MODELS  concept  should  identify  methods  and  procedures  to  collect 
pipeline  performance  measurement  data  at  each  segment  of  the  process  as  it 
occurs.  The  DLSS  should  standardize  the  definition  of  each  pipeline 
segment. 

•  The  MODELS  concept  must  provide  access  to  contract  data  via  various  data 
elements  and  also  establish  and  maintain  relationships  among  data 
elements  through  a  well-designed  data  architecture. 

•  CDRs  should  become  a  part  of  Administrative  Contracting  Officer 
Procurement  Contracting  Officer  data  bases  and  should  be  available  on¬ 
line. 

•  The  use  of  priority  codes,  project  codes,  and  weapons  system  codes  in  the 
requisition  transaction  must  be  defined  and  accommodated  in  the  MODELS 
concept.  Requisition  edits  by  the  supply  source  and  intervening  third 
parties  [such  as  the  Defense  Automatic  Addressing  System  (DAAS)I  need  to 
be  integrated  under  the  DLSS. 

•  MODELS  should  provide  a  better  approach  to  accessing  source-of-supply 
(SOS)  information  and  to  resolving  conflicts. 

•  The  MODELS  concept  must  accommodate  improved  automated  information 
exchange  for  issue  procedures  between  the  depot  and  TCP  as  new 
technologies,  such  as  bar-code  readers,  are  introduced  into  depot  issue 
processing. 

•  The  MODELS  concept  should  provide  the  capability  to  implement  on-line 
user  interfaces  with  ICPs  for  stock  availability  and  requisition  status 
inquiry  for,  at  a  minimum.  Priority  Group  I  materiel  requirements. 

•  The  MODELS  concept  must  provide  a  broad  base  of  DoD  users  with  access 
(not  necessarily  real-time)  to  contracting  and  contract  administration 
activities,  maintaining  information  related  to  contract  content  and  status. 

•  DLSS  procedures  must  provide  for  meeting  the  growing  need  for  inter-S  A 
standardization  of  information  to  be  collected  and  communicated  between 
DoD  transportation  agencies  and  customers,  and  between  DoD  and  commer 
cial  transportation  activities. 

•  The  MODELS  concept  should  provide  for  a  working  interface  between  .Joint 
operations  systems  and  the  DLSS. 

•  The  MODELS  concept  must  be  structured  to  accommodate  rapidly  evolving 
advanced  computer  and  communication  technologies  including  voice  and 
video  communications. 
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•  The  MODELS  concept  requires  a  highly  efficient  and  reliable  system  of 
telecommunications  and  gateway  processors  to  support  inter-S/'A  queries 
and  transfer  of  various  types  of  weapons  system-related  data.  Any  data 
exchange  programs  to  support  weapons  systems  management  must  be 
designed  to  accommodate  classified  data. 

•  Modernized  DLSS  procedures  must  resolve  the  in-transit  visibility  supply- 
transportation  interface  issues  by  providing  specific-item  visibility  during 
the  shipment  process. 

•  The  MODELS  concept  must  provide  for  electronic  exchange  of  large  text- 
fields  of  contract-related  information. 

PROJECT  3-S  REQUIREMENTS 

This  project  enhances  the  LGN  architecture  to  fully  interface  all  defense 
standard  systems  operating  within  the  Department,  including  policies  and 
procedures  external  to  the  DLSS,  but  requiring  inter-S/A  information  exchange  and 
interfaces  with  the  commercial  sector  for  a  full  range  of  electronic  communications. 
It  includes  incorporation  of  3-F  transactions.  Its  requirements’1'  are: 

•  The  MODELS  conceptual  design  should  accommodate  all  information 
exchanges  between  logistics  functions  and  operational/management  compo¬ 
nents. 

•  The  MODELS  concept  should  provide  retail  users  with  direct,  on-line  access 
to  all  retail  supply  echelons  and  the  wholesale  logistics  systems  for 
inquiries  about  stock  availability,  identification  of  retail-issue  requisition 
demand  and  shipment  actions,  in  a  bottom-up,  chain-of-supply  hierarchy. 

•  The  MODELS  concept  should  automate  all  types  of  discrepancvMeficieney 
recordkeeping,  possibly  in  accessible  retail-level  inventory  files. 

•  All  inventory  management  and  control  issues  and  procedures  should  be 
integrated  in  an  expanded  DLSS.  Within  this  integrated  environment,  the 
MODELS  design  must  provide  the  IMM  the  capability  for  semi-real-time, 
on-line  DoD-wide  asset  visibility  to  the  lowest  supply  echelon. 

•  The  MODELS  concept  must  provide  for  exchange  of  transportation 
information/data  with  all  logistics  community  activities  and  also  some 
activities  that  are  not  included  in  the  defense  logistics  operations, 
management  environment,  particularly  JCS,  JDA,  and  the  CINCs. 

•  The  MODELS  concept  must  provide  for  a  reduction  of  paperwork  and  must 
improve  the  flow  of  compatible  data,  on  a  near-real-time  basis  in  some 
cases,  within  the  defense  transportation  function  and  to  and  from  other 
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organizations,  including  commercial  carriers.  Electronic  data  exchange 
concepts  and  standards  must  be  incorporated. 

•  The  MODELS  concept  must  provide  for  evolutionary  development  of  a  near- 
real-time  capability  to  provide  information  and  data  to  assist  the  Military 
Traffic  Management  Command  (MTMC)  in  managing  the  transportation 
function  in  support  of  logistics  activities. 

•  The  MODELS  concept  must  provide  for  a  reasonable  interchange  of 
information  and  data  between  transportation  activities  and  both  nontrans¬ 
portation  and  nonlogistics  activities. 

•  Modernized  DLSS  procedures  and  the  MODELS  information  exchange 
technology  concepts  must  provide  standardized  interfaces  to  unique 
commodity  systems  (e.g.,  ammunition,  petroleum).  Eventually  such  unique 
Service-to-Service  and  Service-to-DLA  procedures  and  automated  systems 
must  be  fully  integrated  into  the  MODELS  concept. 

•  Modernized  DLSS  procedures  must  provide  for  improved  visibility,  i.e.,  the 
ability  to  track  specific  items  at  any  point  in  the  shipment  process. 
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